accountnujen, может и нужно. но я же никогда не разрабатывал авторизацию, user-matching и прочую билеберду. я могу только фантазировать и писать чушь. это вы меня должны просвещать.
accountnujen, не буду. ибо здесь один ответ - не правильный или не совсем точный, можно - с определенной долей условности. а второй защита самой машины. а остальные - ip и фингерприт
фингерпринт можно сделать и на основе user-agent на сервере. да и на js можно закостылить так что бы не увели. но не стоит слушать алкоголиков.
accountnujen, ваша злость от непонимания, того что на том уровне где вы можете поставить куки или сделать связку кука - какие то уникальные данные пользователя, из этих уникальных данных у вас есть только айпи - и какой либо фингерпринт на основе юзер агента, или того что вам сообщит браузер о плагинах, шрифтах и прочем. Точка. Это базовая вещь. По этому задавая такой вопрос - вы получаете ответ базовый. Именно по этому вам ВСЕ написали одинаковые вещи. Но вы от глупости начинаете всем хамить.
psiklop, А я вспомнил этого человека. Оказывается я уже общался с ним по поводу как получить имя файла. В принципе это норма - если чего то не понимать злиться и хамить
Сергей Соколов, а какие еще варианты в таком зоопарке? Будь только http обращения - можно было бы поймать по логу http сервера и modified time. Ну крон так поймать можно. А вот воркеры - хрен
psiklop, чо вы паритесь? ну не знает человек что до сервера долетает только IP и User-Agent, и то с определенной долей условности. Смысл что то обьяснять? На человека опсосы напали и опсосали. Айда бухать.
accountnujen, вы можете смотреть хоть под призмой того что я алкоголик. Однако совет остается прежним. Нагуглите варианты борьбы с перехватом JWT токенов в сингл сессионых приложениях. А я бухать.
можно содержимое подписывать с использование IP пользователя, fingerprint, salt. Соответственно не спасет если вор находится под тем же айпи и использует точно такой же браузер.
Виталий Гусев, можно. НО! НУЖНО, НЕОБХОДИМО, ОБЯЗАТЕЛЬНО использовать подготовленные выражения.. Просто забудьте о существовании id = ".$_GET['userid'].". Нет такого больше
Сергей c0re, запрос where id in (1, 2, 5, 10) без order by может вернуть 1,2,5,10. может вернуть 2,5,1,10. может вернуть 10,5,2,1 - ибо постгрес будет возвращать записи в том порядке в котором нашел. А искать он будет сначала в кеше, потом на диске. В одну секунду он в кеше увидел 1,2 во вторую 5,10. С диском тоже не все гладко - потому что mvcc и всякие оптимизации ни хрена не гарантируют порядок. Да и вообще понятие порядок отсутствует. Следовательно первый апдейт выборкой where in получил что сначала он ему надо изменить запись с id 1, потом с id 5, он лочит запись с id 1, правит, и пытается получить лок на запись c id 5. Второй запрос update получил сначала запись с id 5, лочит правит и пытается получить лок на запись с id 1. Deadlock.
В случае с select order by мы гарантируем что все апдейты у нас получат один порядок. Запрос 1 получает 1,2,5,10. Лочит запись с id 1, правит, лочит c id 2, правит....... Второй запрос получает 1,2,5,10 - пытается получить лок на запись с id 1 - видит что залочена - ждет. Deadlock нет. В статье даже картинка есть
Сергей c0re, статью прочитайте абзац Упреждающая блокировка FOR UPDATE. Проблема с деадлоками здесь возникает здесь потому что строки для update постгрес будет выдавать в неопределенном порядке. и по этому может возникнуть ситуация когда первый запрос схватил 1 строку, и пытается получить вторую, а второй параллельный запрос схватит 2, и будет ждать 1 строку. по этому когда мы гвоздям упорядочиваем строки для апдейта - такой ситуации не будет. собственно и без lock update должно работать
З.Ы. Нахрена я ссылку на статью то привел?
З.З.Ы у меня сильное подозрение что использование ctid здесь перестраховка. Не говоря о том что я отвечал на вопрос с деадлоками - а уже потом искал статью с объяснениями почему оно так. Но судя по всему зря искал :)