Писал как-то Sergey Poziturin к Dmitriy Romanov примерно 18 Июн 15 в 14:09 А я смотрю и фигею.
SP>>>>> По срокам: я планирую запустить всё это в промышленную SP>>>>> эксплуатацию в течение 1-2 недель. Все, кто к этому времени SP>>>>> пришлёт описание и настроит узлы, получат некоторое количество SP>>>>> новых поинтов. Мой узел в списке тоже будет. Вся часть с SP>>>>> запросами уже реализована, сейчас работаю над списками SP>>>>> конференций. В релизе будет всё и сразу. DR>>>> Hеплохо было бы предусмотреть какую-никакую капчу, а то спамботы DR>>>> могут навалить. Можно конечно сразу не включать, но возможность DR>>>> таковой предусмотреть очень желательно было бы. SP>>> Поясни, чего конкретно ты боишься? У меня статистика следующая: SP>>> за 1.5 года запросов на получение поинта от робота - 0 (нуль). SP>>> Это и понятно, в ближайшие годы едва ли роботы начнут покупать SP>>> мобильные телефоны. Если ты о том, что твой скрипт начнут дёргать SP>>> боты, то это можно будет преодолеть легко без капчи, просто введя SP>>> некое проверочное значение, например sha-512 от имени SP>>> пользователя и там к примеру адреса узла. Сервер его тоже SP>>> посчитает, сверит с присланным, и всё. Такая себе защита от SP>>> любителей дёргать чужие cgi. Hо это если проблема выглядит SP>>> реальной. DR>> Таки бот догадается то же самое посчитать. А если для этого данные DR>> будут зашиты в приложении - то получается закрытый формат обмена, DR>> что тоже не гуд. Надо лишь предусмотреть такую возможность. Не DR>> факт, что она понадобится. Но отсутствие таковой - это DR>> потенциальные грабли. Незачем их оставлять, раз уж о них DR>> вспомнили. SP> Бот догадается? Ты шутишь? Ну не сам бот конечно, но его автор - вполне.
SP>>> Hо моё имхо следующее: просто отклоняй все запросы, в которых не SP>>> заполнены все поля. У тебя же нет веб-формы, в которую робот SP>>> пишет и жмёт submit, у тебя просто скрипт, который а) едва ли SP>>> индексируется поисковиками и б) принимает набор неизвестных ботам SP>>> параметров, т.к. формы нет. DR>> Если это будет описано где-либо, хоть даже в этой эхе, то это уже DR>> вполне себе известный набор параметров. И для спамбота лишнюю DR>> незакрываемую дырку оставлять не хочется. SP> Ладно, пришли код на java, посмотрю, как можно его применить. Не, ява - это не мое.
SP>>> А на будущее можно и подумать о чём-то более сложном. Hапример SP>>> при регистрации через веб-сайт уже можно иметь и капчу, но это SP>>> уже не относится к cgi твоему и протоколу обмена с инициатором SP>>> запроса. DR>> А почему бы не унифицировать обмен через веб-форму и через DR>> приложение? SP> Он унифицирован полностью. Почувствуй разницу между интерфейсом с SP> пользователем и с сервером. Первый может быть любым, хоть с капчей, SP> хоть с блэкджеком. А во второй это всё тащить смысла нет. Тут всё SP> должно быть максимально просто. Я рисков не вижу. Так и там и там http запросы, что они будут формой состряпываться, что то же самое прогой делаться