Forum Webscript.Ru
Программирование => PHP => Тема начата: pomidor от 06 Июня 2002, 10:22:08
-
Пишу, значит, voting poll - голосование. Каким образом посоветуете блокировку IP-адреса юзверя, после того как он проголосовал. Блокировать надо или на 1 день, или навсегда (тоесть необходимы оба варианта).
я вижу такие варианты:
1. писать сессию - задавать соответствующее время жизни
2. писать куку - аналогично
3. писать в базу.
какой из вариантолв лучше? какие еще есть?
заранее спасибо за советы/ответы
-
что, никто не знает? а я думал что это довольно простой вопрос... или просто лень на такой вопрос отвечать? ну помогите же!
-
ага - лень. честно... у этого форума есть средство поиска
-
Кука + база.
-
япс! все понял :)
сорри за напряги :D :D :D
-
1. Невозможно в принципе.
2. При чем тут IP?
3. Единственный вариант - других нету..
-
RomikChef
Единственный вариант - других нету
Неправда.
Кука используется для того, чтобы отлавливать ходящих с динамическими адресами или через проксю.
-
В принципе, ты прав.
Только надо тогда вопрос переформулировать - не блокировка IP а блокировка уже голосовавших :-)
Хотя все равно, кто захочет - тот накрутит :-)
-
почему невозможно сессией? по-моему очень даже можно... ловлю координаты юзера и пишу в сессию у себя, а в куку у него. при повторном визите (попытке голосовать) - проверка на вшивость. если нет ни того, ни другого - позволяем, если одно есть или оба - посылаем на три... если даже с динамической или по проксям - сессия его не узнает, а кука - запросто сдаст как стеклотару... и все обходится без базы.
или я не прав?
-
Сессия - это сеанс работы пользователя с сайтом. Пока он не закрыл броузер.
Использовать сессии для отслеживания чего-то другого -неправильно и бессмысленно.
По поводу куки, которая сдаст как стеклотару. А если ее стереть? ;-)
-
По поводу куки, которая сдаст как стеклотару
А вот для этого и пишется айпишник.
Все равно 100% защиты нет в принципе.
-
100% нет. Но добиться такого уровня, чтоб рядовому человеку в облом было искать обходные пути - неф делать...
Использовать сессии для отслеживания чего-то другого -неправильно и бессмысленно.
ну и что из того? но ведь получается! по понятиям W3C если в доке не указано DOCTYPE, то он вообще как бы должен рендериться как текст... А сколько из нас используют этот тег??? Стандарты - это одно. А изворотливость в разных ситуациях - совсем другое. Что мне мешает хранить у себя на сервере сессию пока мне этого захочется? Ничто. Могу годами хранить... А вот куку действительно юзер может стереть. Но при наличии сессии и отсутствии куки скрипт все равно не позволит голосовать... И впишет еще одну куку :)
-
Но при наличии сессии и отсутствии куки скрипт все равно не позволит голосовать...
Можно вот эту часть осветить поподробнее?
Значит, я твой юзер. Зашел, проголосовал. Вышел, убил все куки на твой домен, захожу снова. Действия твоего скрипта?
А к стандартам надо относиться вежливо.
-
Насчет стандаров я хотел сказать, что прежде, чем их нарушать, надо сначала понять - для чего они служат, и как работают.
-
я ж писал уже... проверяем наличие куки И сессии. Если хотя бы одно присутствует - говорим: "дорогой юзер, я тебя кажется уже где-то видел..." и выводим результаты.
если ты не в курсе, сессия, согласно мануале по ПХП, лежит на сервере, и командовать ею могу только я. Юзер удалить свою сессию не может. А если я укажу сессии жить не до конца сеанса, как по умолчанию, а попрошу ее полежать немного дольше. А в 00:00 каждый день Crontab будет запускать скрипт, который будет удалять все старые сессии за этот день...
так понятно? или пример написать и на сервер кинуть, для полной проверки?
-
Идентификатор сессии передается в куках, либо в урле, если он теряется создается новая сессия. Если я убил куки и зашел снова с пустым урлом - как тогда узнать?
-
Лежит-лежит твоя сессия на сервере.
я с этим не спорю.
Я спрашиваю - как ты отличишь, что это именно я пришел, у которого сессия час назад была?
Если у меня стоит сессионная кука - то сессия твоя неправильная меня признает. А если я куку стер - то увы.
Поэтому я и говорю, что использовать сессии - бесполезно, поскольку в данном случае они ничем не отличаются от кук, только более тяжеловесны - ты зря загружаешь свой сервер.
И еще, каким образом будет твой скрипт по кронтабу прибивать сессии? Какой командой?
-
2 Britva & RomikChef
да, соглашаюсь... не учел идентификатор... прошу всеобщего прощения :)
а если такой вариант: мы для генерации идентификатора сессии будем использовать не стандартный PHPSESSID а именно IP посетителя? или я вообще что-то несуразное гоню? :| :| :| :| :|
а с кронтабом все просто - он запускает ПХП-скрипт, который проверяет время создания сессии (его как переменную можно вложить в саму сессию). и если время больше допустимого лимита - сессия удаляется. хотя, честно говоря, это тоже уродство. сессия сама себя по истечении срока действия удалит, правда?
что-то я вообще сегодня гоню... ничего, зато ошибки свои понял :) спасибо всем, особенно тебе RomikChef за придирство к мелочам!
-
и еще... поскольку моя версия ушла в заднее место, принимаю дельные предложения по реализации этой схемы :)
кстати, видать именно моя неправота спровоцировала такое бурное обсуждение. а это хорошо, потому что до этого довольно долгое время все молчали...
еще раз спасибо
-
Мда, впервые в жизни меня благодарят за придирство...
По поводу сессий.
Беда в том, что ты себе представляешь все это очень абстрактно.
Вот ты говоришь "скрипт, который проверяет время создания сессии ". Какой сессии? Он берет откуда-то список? Откуда? Стандартно ид сессии приходит от браузера клиента. А здесь? Наверное, как-то можно извратиться, и читать напрямую файлы сессий, перебирать, анализировать и убивать...
Но это не кажется мне удачным решением.
По поводу голосования.
Комбинировать куку и IP я считаю нецелесообразным - слишком разные методы. Кука идет клиенту, а айпи - в базу.
Я бы делал так.
1. проверял, работают ли куки. Если нет - вежливо извинялся о недоступности голосования.
2. Если да - давал голосовать и ставил куку со временем голосования
3. в зависимости времени из куки выводил или нет форму.
4. Писал бы лог - с айпи и временем голосования. Но никак бы по айпи не ограничивал.
Объясняю. Берем нормального юзера. Он проголосовал. Все нормально.
Берем хакера. Он стирает куку и голосует. УРА! Накрутка работает. Он накручивает и благополучно ложится спать.
Утром тебе скриптик доклабывает - с такого-то айпи подано 100 голосов. Ты их по-тихому вырезаешь.
Если же хакер видит, что его забанили по айпи, то он начинает искать прокси и всякие другие гадости.
Правда, у меня давно уже бродит в голове идея проверять айпи-адреса на наличие анонимного прокси на этом адресе, и автоматически не пускать с таких адресов.
-
Ты их по-тихому вырезаешь.
Если же хакер видит, что его забанили по айпи, то он начинает искать прокси и всякие другие гадости.
зачем? лучшая борьба против этих хакеров - это сохранять спокойствие. никаких резких движений, т.е. не нужно банить ip. создается черный список, а в конце голосования - подсчет.
Правда, у меня давно уже бродит в голове идея проверять айпи-адреса на наличие анонимного прокси на этом адресе, и автоматически не пускать с таких адресов.
а если приходится иногда работать с самого сервера?
или, к примеру, другого варианта выхода в инет нет?
честные юзвери будут обделены.
ps. а цели оправдывают средства? имеет смысл так убиваться?
-
не нужно банить ip. создается черный список, а в конце голосования - подсчет.
вот это кажется трезвая идея. и главное: работоспособная! по сути мне не в облом в конце пересчитать (понятно, шо не руцями) голоса, таким образом по логах можно определить факты накрутки и такие голоса не считать... а при публикации итогов голосования написать чё-то типа: в связи с попытками накрутки голосов данные были повторно обработаны и откорректированы.
-
гм... А как ты проверишь наличие сессии без кукисов? Ты доку по пхп читал? Или я чего-то не понимаю?
"There are two methods to propagate a session id:
Cookies
URL parameter"
второе очень красиво и быстро убирается.
Можно только проверять на наличие IP, но тогда как быть с динамическими адресами?
-
динамическими адресами
Для этот кукисы и используются (делаются попытки использовать)
-
Утром тебе скриптик доклабывает - с такого-то айпи подано 100 голосов. Ты их по-тихому вырезаешь.
А как быть с пользователями больших корпоративных сетей?
(ну вот та же институтская сеть, КПИ к примеру)
Тут через один IP может несколько тысяч человек ходить.
Можно только сравнивать время с одного IP -- если нерегулярно заходят, то все ОК
(насчет предыдущей мессаги сорри -- не видел что уже ответили толково)
-
А как быть с пользователями больших корпоративных сетей?
Либо теже куки либо ловить X_HTTP_FORWARDED_FOR (прокси)
Ессно, если прокси анонимный, то толку от этой переменной никакого.
-
yaroslaw
Если бы у бабушки было кое-что, то она была бы дедушкой.
А куки всему интституту ректор отрубил?