Здравствуйте, DeMx, Вы писали:
DM>Есть каталог сайтов. Самописный, млин. Так вот, все вроде написано и работает. Осталось только сделать проверку на повторное голосование за сайт и голосавание от самого админа. Я просто не много не понимаю сам принцип... DM>Требуется: DM>- запретить голосовать одному посетителю больше одного раза за сайт; DM>- запретить голосовать администратору сайта (тот, кто будет заполнять форму о добавлении сайта в каталог) за свой же ресурс.
DM>Я так понимаю, что все это реализуется записью IP-адреса каждого проголосовавшего в базу. Затем просто нужно будет искать при очередном добавлении голоса совпадения. Плюс еще нужно будет записывать IP'шник админа, чтоб и его потом проверять. Так ли я все это понимаю? Может есть какие-то мелкие ньюансы, облегчающие работу со всем этим? Какие вообще варианты есть? Может эффективней просто в файл все IP'шники записывать?
Все предложенные варианты слабы, если голосующий хоть чуток продвинут.
Предлагаю идентифицировать помимо куки, устанавливаемого при голосовании, (который многие вытрут) по комбинации IP и хидера отсылаемого браузером (только надо внимательно глянуть, что из него брать действительно устойчивого и индивидуального: языковые и MIME приоритеты, плагины и т.д). В таком случае специалист по вытиранию куки сможет проголосовать меньшее количество раз, если же дополнить форму голосования клиентским скриптом записывающим в куки специфическую информацию (разрешение, цветность и т.д.), то можно ещё более повысить вероятность, что не будет отказанно в голосовании двум компьютерам с одного IP и совпадающими хидерами браузеров.
Есть каталог сайтов. Самописный, млин. Так вот, все вроде написано и работает. Осталось только сделать проверку на повторное голосование за сайт и голосавание от самого админа. Я просто не много не понимаю сам принцип...
Требуется:
— запретить голосовать одному посетителю больше одного раза за сайт;
— запретить голосовать администратору сайта (тот, кто будет заполнять форму о добавлении сайта в каталог) за свой же ресурс.
Я так понимаю, что все это реализуется записью IP-адреса каждого проголосовавшего в базу. Затем просто нужно будет искать при очередном добавлении голоса совпадения. Плюс еще нужно будет записывать IP'шник админа, чтоб и его потом проверять. Так ли я все это понимаю? Может есть какие-то мелкие ньюансы, облегчающие работу со всем этим? Какие вообще варианты есть? Может эффективней просто в файл все IP'шники записывать?
По поводу идентификации пользователей по IP. А ты не думал, что бывает такое, что юзеры ходят в инет через проксю? Например организация из 1000 человек может сидеть за одной проксей, а ты их всех будешь идентифицировать как одного человека. Или тот же диал-ап — там IP-шник из пула может сотни раз за день выдаваться разным людям...
Здравствуйте, DrZubr, Вы писали:
DZ>По поводу идентификации пользователей по IP. А ты не думал, что бывает такое, что юзеры ходят в инет через проксю? Например организация из 1000 человек может сидеть за одной проксей, а ты их всех будешь идентифицировать как одного человека. Или тот же диал-ап — там IP-шник из пула может сотни раз за день выдаваться разным людям...
Вроде есть два варианта для этого: сессия и/или кукование
Здравствуйте, bopka_, Вы писали:
_>Здравствуйте, DrZubr, Вы писали:
DZ>>По поводу идентификации пользователей по IP. А ты не думал, что бывает такое, что юзеры ходят в инет через проксю? Например организация из 1000 человек может сидеть за одной проксей, а ты их всех будешь идентифицировать как одного человека. Или тот же диал-ап — там IP-шник из пула может сотни раз за день выдаваться разным людям...
_>Вроде есть два варианта для этого: сессия и/или кукование
А что тогда записывать в куки? У меня нету никакой однозначной идентификации пользователей, голосующих за сайты, т.к. голосование устроено без регистрации (любой прохожий может рейтинг сайту увеличить)...
Здравствуйте, DeMx, Вы писали:
_>>Вроде есть два варианта для этого: сессия и/или кукование DM>А что тогда записывать в куки? У меня нету никакой однозначной идентификации пользователей, голосующих за сайты, т.к. голосование устроено без регистрации (любой прохожий может рейтинг сайту увеличить)...
Нужно создать уникальную переменную сессии — обычно, это случайный длинный набор знаков, и использовать её, как идентификатор.
Здравствуйте, bopka_, Вы писали:
_>Здравствуйте, DeMx, Вы писали:
_>>>Вроде есть два варианта для этого: сессия и/или кукование DM>>А что тогда записывать в куки? У меня нету никакой однозначной идентификации пользователей, голосующих за сайты, т.к. голосование устроено без регистрации (любой прохожий может рейтинг сайту увеличить)...
_>Нужно создать уникальную переменную сессии — обычно, это случайный длинный набор знаков, и использовать её, как идентификатор.
Хм, вот такого мне еще не предлагали. =) А как это сделать?
Здравствуйте, DeMx, Вы писали:
_>>Нужно создать уникальную переменную сессии — обычно, это случайный длинный набор знаков, и использовать её, как идентификатор. DM>Хм, вот такого мне еще не предлагали. =) А как это сделать?
Это, вроде, стандартный способ
Если в PHP, то посмотри здесь
Здравствуйте, bopka_, Вы писали:
_>Нужно создать уникальную переменную сессии — обычно, это случайный длинный набор знаков, и использовать её, как идентификатор.
По-моему ты что-то не то человеку советуешь...
При чем здесь "уникальная переменная сессии"??? Ведь вопрос то стоит про голосование без регистрации.
Здравствуйте, DeMx, Вы писали:
DM>А что тогда записывать в куки? У меня нету никакой однозначной идентификации пользователей, голосующих за сайты, т.к. голосование устроено без регистрации (любой прохожий может рейтинг сайту увеличить)...
Во-первых, если у тебя голосование без регистрации, то отличать пользователей следует по кукам. Но учти что это совсем не 100% способ — парень может и почистить куки, так что он накруток это в общем не спасет...
А в куки писать нужно уникальный id-шник пользователя (можно например брать большой рандом — будет достаточно надежный uid).
Здравствуйте, DrZubr, Вы писали:
DZ>Здравствуйте, bopka_, Вы писали:
_>>Нужно создать уникальную переменную сессии — обычно, это случайный длинный набор знаков, и использовать её, как идентификатор.
DZ>По-моему ты что-то не то человеку советуешь... DZ>При чем здесь "уникальная переменная сессии"??? Ведь вопрос то стоит про голосование без регистрации.
Если нет регистрация — то сессия или кука — единственный способ установить, был он здесь или нет, что бы не голосовал по второму разу
Здравствуйте, bopka_, Вы писали:
_>Если нет регистрация — то сессия или кука — единственный способ установить, был он здесь или нет, что бы не голосовал по второму разу
Ну при чем здесь сессия? Как ты предлагаешь использовать сессию?
Здравствуйте, DrZubr, Вы писали:
DZ>Здравствуйте, bopka_, Вы писали:
_>>Если нет регистрация — то сессия или кука — единственный способ установить, был он здесь или нет, что бы не голосовал по второму разу
DZ>Ну при чем здесь сессия? Как ты предлагаешь использовать сессию?
Ну не обязвтельно сессия — просто какой-то уникальный ключ, показывающий, что пользователь там уже был, что то вроде
При первом входе на страницу пользователь получает этот ключ, и если входит туда ещё раз, производится проверка на наличие этого ключа. Если ключ есть — голосование запрещается.
Здравствуйте, bopka_, Вы писали:
_>Ну не обязвтельно сессия — просто какой-то уникальный ключ, показывающий, что пользователь там уже был, что то вроде _>
ИМХО, довольно странный и ненужный гемор с hidden-полем... Зачем оно?
_>При первом входе на страницу пользователь получает этот ключ,
Что значит получает ключ? Куда он его получает?
_>и если входит туда ещё раз, производится проверка на наличие этого ключа. Если ключ есть — голосование запрещается.
писал как стоит делать (IMHO).
Повторю еще раз.
1. Когда парень жмет "Проголосовать", проверяем есть ли у него на куках наш uid.
а) если есть — смотрим не голосовал ли он раньше за этот сайт и не админ ли он. Если да — посылаем его. Иначе — защитываем результат голосования и помечаем, что он уже проголосовал за этот сайт.
б) если нет — генерим uid, записываем куку, защитываем результаты голосования, помечаем что проголосовал.
2. При генерации страницы с голосованием проверяем uid на куках. Если он есть и парень уже участвовал в этом голосовании или он админ — вырезаем возможность проголосовать. Иначе — отображаем голосование.
писал как стоит делать (IMHO). DZ>Повторю еще раз. DZ>1. Когда парень жмет "Проголосовать", проверяем есть ли у него на куках наш uid. DZ>а) если есть — смотрим не голосовал ли он раньше за этот сайт и не админ ли он. Если да — посылаем его. Иначе — защитываем результат голосования и помечаем, что он уже проголосовал за этот сайт. DZ>б) если нет — генерим uid, записываем куку, защитываем результаты голосования, помечаем что проголосовал. DZ>2. При генерации страницы с голосованием проверяем uid на куках. Если он есть и парень уже участвовал в этом голосовании или он админ — вырезаем возможность проголосовать. Иначе — отображаем голосование.
Ну и..?
Я про то же самое говорю. Только, если пользователь куку отключит, придётся uid передавать по форме через POST
Здравствуйте, bopka_, Вы писали:
_>Ну и..? _>Я про то же самое говорю. Только, если пользователь куку отключит, придётся uid передавать по форме через POST
Я так понимаю, что тебя убедить невозможно.
И смысл передавать uid через POST? Ведь его тогда придется таскать не только в post-формах, но и в get-ссылках. К тому же после того как пользователь закроет наш сайт, мы его уже не идентифицируем в следующий заход на сайт. И к чему тогда эти танцы с бубном только ради того чтобы не дать юзеру проголосовать несколько раз в течении одного сеанса работы с сайтом??
ИМХО, в данной ситуации, когда нужно сделать голосование без регистрации имеет смысл ориентироваться только на куки, а если они отключены, то посылать такого парня.
Здравствуйте, DrZubr, Вы писали:
DZ>Здравствуйте, bopka_, Вы писали:
_>>Ну и..? _>>Я про то же самое говорю. Только, если пользователь куку отключит, придётся uid передавать по форме через POST
DZ>Я так понимаю, что тебя убедить невозможно.
В чём?
DZ>И смысл передавать uid через POST? Ведь его тогда придется таскать не только в post-формах, но и в get-ссылках.
Факт — если нет возможности пользоваться куками, нужно таскать этот uid везде
DZ>ИМХО, в данной ситуации, когда нужно сделать голосование без регистрации имеет смысл ориентироваться только на куки, а если они отключены, то посылать такого парня.
В принципе да, всё остальное имелось в виду "на крайний случай"
Здравствуйте, bopka_, Вы писали:
_>Здравствуйте, DrZubr, Вы писали:
DZ>>Я так понимаю, что тебя убедить невозможно. _>В чём?
В том что в случае DeMx особо нет смысла в сессии (таскание uid через параметр запроса — это фактически та же сессия)
DZ>>И смысл передавать uid через POST? Ведь его тогда придется таскать не только в post-формах, но и в get-ссылках. _>>Факт — если нет возможности пользоваться куками, нужно таскать этот uid везде
Не факт. Смысл??? Зачем устраивать лишний гемор, который всего лишь не даст проголосовать дважды в течении одной сессии?
DZ>>ИМХО, в данной ситуации, когда нужно сделать голосование без регистрации имеет смысл ориентироваться только на куки, а если они отключены, то посылать такого парня. _>В принципе да, всё остальное имелось в виду "на крайний случай"
С такими крайними случаями...
bopka_ wrote: > Если нет регистрация — то сессия или кука — единственный способ > установить, был он здесь или нет, что бы не голосовал по второму разу
И то "от честных людей" — не помогает от тех, кто хочет.
bodya wrote: > Все предложенные варианты слабы, если голосующий хоть чуток продвинут. > Предлагаю идентифицировать помимо куки, устанавливаемого при > голосовании, (который многие вытрут) по комбинации IP и хидера > отсылаемого браузером (только надо внимательно глянуть, что из него > брать действительно устойчивого и индивидуального: языковые и MIME > приоритеты, плагины и т.д). В таком случае специалист по вытиранию куки > сможет проголосовать меньшее количество раз, если же дополнить форму > голосования клиентским скриптом записывающим в куки специфическую > информацию (разрешение, цветность и т.д.), то можно ещё более повысить > вероятность, что не будет отказанно в голосовании двум компьютерам с > одного IP и совпадающими хидерами браузеров.
Накрутчик вынужден будет взять FF+UserAgentSwitcher или учить HTTP. Даже
в этом случае польза будет. Хорошее решение.
Здравствуйте, raskin, Вы писали:
R>Накрутчик вынужден будет взять FF+UserAgentSwitcher или учить HTTP. Даже R>в этом случае польза будет. Хорошее решение.
А также обламаются все юзвери сидящие за одной проксей, у которых стоит одинаковый браузер. Чаще всего в организациях железо ставится практически одинаковое, да и систему настраивает один админ...
Здравствуйте, DeMx, Вы писали:
DM>Есть каталог сайтов. Самописный, млин. Так вот, все вроде написано и работает. Осталось только сделать проверку на повторное голосование за сайт и голосавание от самого админа. Я просто не много не понимаю сам принцип... DM>Требуется: DM>- запретить голосовать одному посетителю больше одного раза за сайт; DM>- запретить голосовать администратору сайта (тот, кто будет заполнять форму о добавлении сайта в каталог) за свой же ресурс.
DM>Я так понимаю, что все это реализуется записью IP-адреса каждого проголосовавшего в базу. Затем просто нужно будет искать при очередном добавлении голоса совпадения. Плюс еще нужно будет записывать IP'шник админа, чтоб и его потом проверять. Так ли я все это понимаю? Может есть какие-то мелкие ньюансы, облегчающие работу со всем этим? Какие вообще варианты есть? Может эффективней просто в файл все IP'шники записывать?
Если ты даеш голосовать всем подряд, то ненадо ничего выдумывать, тот кто захочет накрутить рейтинг
накрутит полюбому. Иначе тебе придется считать рейтинг только от зарегиных юзеров.
Используй сессионную переменную PHPSESSID для идентификаии юзеров, если куки включены она запишется в куки.
Потом проверяй со своей базой был ли этот юзер раньше с переменной PHPSESSID.
В любом случае использовать сессии предпочтительней, чем самому генерировать случайные числа и записывать их в
куксы.
З.Ы. Забей на все проверки, пускай все голосуют столько сколько им надо. Единственное с помощью сессий,
можеш запретить голосовать в одном сеансе более 2 раз!
Например организация из 1000 человек может сидеть за одной проксей, а ты их всех будешь идентифицировать как одного человека. Или тот же диал-ап — там IP-шник из пула может сотни раз за день выдаваться разным людям...
ICQ [168117153]
