блокировка IP - варианты

[Britva]

Идентификатор сессии передается в куках, либо в урле, если он теряется создается новая сессия. Если я убил куки и зашел снова с пустым урлом - как тогда узнать?

[Меняздесьдавнонет]

Лежит-лежит твоя сессия на сервере.
я с этим не спорю.
Я спрашиваю - как ты отличишь, что это именно я пришел, у которого сессия час назад была?
Если у меня стоит сессионная кука - то сессия твоя неправильная меня признает. А если я куку стер - то увы.

Поэтому я и говорю, что использовать сессии - бесполезно, поскольку в данном случае они ничем не отличаются от кук, только более тяжеловесны - ты зря загружаешь свой сервер.

И еще, каким образом будет твой скрипт по кронтабу прибивать сессии? Какой командой?

[pomidor]

2 Britva & RomikChef

да, соглашаюсь... не учел идентификатор... прошу всеобщего прощения
а если такой вариант: мы для генерации идентификатора сессии будем использовать не стандартный PHPSESSID а именно IP посетителя? или я вообще что-то несуразное гоню? :| :| :| :| :|

а с кронтабом все просто - он запускает ПХП-скрипт, который проверяет время создания сессии (его как переменную можно вложить в саму сессию). и если время больше допустимого лимита - сессия удаляется. хотя, честно говоря, это тоже уродство. сессия сама себя по истечении срока действия удалит, правда?

что-то я вообще сегодня гоню... ничего, зато ошибки свои понял спасибо всем, особенно тебе RomikChef  за придирство к мелочам!

[pomidor]

и еще... поскольку моя версия ушла в заднее место, принимаю дельные предложения по реализации этой схемы

кстати, видать именно моя неправота спровоцировала такое бурное обсуждение. а это хорошо, потому что до этого довольно долгое время все молчали...

еще раз спасибо

[Меняздесьдавнонет]

Мда, впервые в жизни меня благодарят за придирство...
По поводу сессий.
Беда в том, что ты себе представляешь все это очень абстрактно.
Вот ты говоришь "скрипт, который проверяет время создания сессии ". Какой сессии? Он берет откуда-то список? Откуда? Стандартно ид сессии приходит от браузера клиента. А здесь? Наверное, как-то можно извратиться, и читать напрямую файлы сессий, перебирать, анализировать и убивать...
Но это не кажется мне удачным решением.

По поводу голосования.
Комбинировать куку и IP я считаю нецелесообразным - слишком разные методы. Кука идет клиенту, а айпи - в базу.
Я бы делал так.
1. проверял, работают ли куки. Если нет - вежливо извинялся о недоступности голосования.
2. Если да - давал голосовать и ставил куку со временем голосования
3. в зависимости времени из куки выводил или нет форму.
4. Писал бы лог - с айпи и временем голосования. Но никак бы по айпи не ограничивал.
Объясняю. Берем нормального юзера. Он проголосовал. Все нормально.
Берем хакера. Он стирает куку и голосует. УРА! Накрутка работает. Он накручивает и благополучно ложится спать.
Утром тебе скриптик доклабывает - с такого-то айпи подано 100 голосов. Ты их по-тихому вырезаешь.
Если же хакер видит, что его забанили по айпи, то он начинает искать прокси и всякие другие гадости.

Правда, у меня давно уже бродит в голове идея проверять айпи-адреса на наличие анонимного прокси на этом адресе, и автоматически не пускать с таких адресов.

[Dm]

Ты их по-тихому вырезаешь.
Если же хакер видит, что его забанили по айпи, то он начинает искать прокси и всякие другие гадости.

зачем? лучшая борьба против этих хакеров - это сохранять спокойствие. никаких резких движений, т.е. не нужно банить ip. создается черный список, а в конце голосования - подсчет.

Правда, у меня давно уже бродит в голове идея проверять айпи-адреса на наличие анонимного прокси на этом адресе, и автоматически не пускать с таких адресов.

а если приходится иногда работать с самого сервера?
или, к примеру, другого варианта выхода в инет нет?
честные юзвери будут обделены.

ps. а цели оправдывают средства? имеет смысл так убиваться?

[pomidor]

не нужно банить ip. создается черный список, а в конце голосования - подсчет.

вот это кажется трезвая идея. и главное: работоспособная! по сути мне не в облом в конце пересчитать (понятно, шо не руцями) голоса, таким образом по логах можно определить факты накрутки и такие голоса не считать... а при публикации итогов голосования написать чё-то типа: в связи с попытками накрутки голосов данные были повторно обработаны и откорректированы.

[yaroslaw]

гм... А как ты проверишь наличие сессии без кукисов? Ты доку по пхп читал? Или я чего-то не понимаю?

"There are two methods to propagate a session id:
Cookies
URL parameter"
второе очень красиво и быстро убирается.

Можно только проверять на наличие IP, но тогда как быть с динамическими адресами?

[ThE0ReTiC]

динамическими адресами

Для этот кукисы и используются (делаются попытки использовать)

[yaroslaw]

Утром тебе скриптик доклабывает - с такого-то айпи подано 100 голосов. Ты их по-тихому вырезаешь.  

А как быть с пользователями больших корпоративных сетей?
(ну вот та же институтская сеть, КПИ к примеру)
Тут через один IP может несколько тысяч человек ходить.

Можно только сравнивать время с одного IP -- если нерегулярно заходят, то все ОК

(насчет предыдущей мессаги сорри -- не видел что уже ответили толково)

[ThE0ReTiC]

А как быть с пользователями больших корпоративных сетей?

Либо теже куки либо ловить X_HTTP_FORWARDED_FOR (прокси)
Ессно, если прокси анонимный, то толку от этой переменной никакого.

[Меняздесьдавнонет]

yaroslaw
Если бы у бабушки было кое-что, то она была бы дедушкой.
А куки всему интституту ректор отрубил?