= Сообщение: 2679 из 14902 ======================================= R50.SYSOP =
От : Sergey Poziturin 2:5020/2141.3 18 Jun 15 14:09:18
Кому : Dmitriy Romanov 18 Jun 15 14:09:18
Тема : Про набор поинтов сисопами и продолжен и е сети
FGHI : area://R50.SYSOP?msgid=2:5020/2141.3+e69dbfdf
На : area://R50.SYSOP?msgid=2:6078/1+55808c2f
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://R50.SYSOP?msgid=2:6078/1+5582c8d0
==============================================================================
Hello, Dmitriy Romanov.
On 16.06.15 22:44 you wrote:
SP>>>> 2. Юзер выбирает желаемый узел, заполняет ФИО, пароль, мыло,
SP>>>> несколько слов о себе и нажимает кнопку "Submit", после чего
SP>>>> запрос улетает на узел. Каким образом улетает запрос, зависит
SP>>>> от указанного в XML, это может быть как http[s]-запрос, так и
SP>>>> обычный e-mail на указанный адрес. - В случае http, в
SP>>>> POST-параметрах передаются данные пользователя, а в ответ
SP>>>> сервер должен сообщить адрес присвоенного поинта. Этот адрес
SP>>>> записывается в настройки хотдога.
DR>>> А можно предусмотреть вариант GET-запроса с параметрами в
DR>>> строке? Я бы тогда мог при случае накрапать cgi для этих целей.
SP>> Да предусмотреть можно, но ты мне скажи, плз, в чём для тебя в
SP>> CGI разница между переменными post и get?
DR> По сути - никакой. А по факту - просто лень разбираться с post.
Ну вы блин даете. (с)
Извини, в моих обстоятельствах это не аргумент.
SP>>>> Полный формат - в каждом файле следующая информация об эхе
SP>>>> через запятую: название,unixtime последнего
SP>>>> сообщения,количество сообщений[,описание эхи] Пример: ==
SP>>>> pushkin.local,1434352755,19698,Pushkin's local echo
SP>>>> su.kitchen,1434352123,150,Kitchen zzz.abc,1434352755,89,
SP>>>> test.echo,1434352755,112 ==
DR>>> Hеплохо бы все поля кроме названия эхи сделать опциональными.
DR>>> Hапример r50.sysop,,1024,
SP>> Ок. Можно будет и без последней запятой.
DR> В таком случае отпадает надобность в сокращенном формате - он
DR> является лишь частным случаем полного.
Нет, не отпадает. Поинт увидит визуальные различия между узлами при выборе в списке. Ранжирование отменили, но признак есть.
Никто, конечно, не запрещает обманывать, но зачем это делать?
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>> Hо моё имхо следующее: просто отклоняй все запросы, в которых не
SP>> заполнены все поля. У тебя же нет веб-формы, в которую робот
SP>> пишет и жмёт submit, у тебя просто скрипт, который а) едва ли
SP>> индексируется поисковиками и б) принимает набор неизвестных ботам
SP>> параметров, т.к. формы нет.
DR> Если это будет описано где-либо, хоть даже в этой эхе, то это уже
DR> вполне себе известный набор параметров. И для спамбота лишнюю
DR> незакрываемую дырку оставлять не хочется.
Ладно, пришли код на java, посмотрю, как можно его применить.
SP>> А на будущее можно и подумать о чём-то более сложном. Hапример
SP>> при регистрации через веб-сайт уже можно иметь и капчу, но это
SP>> уже не относится к cgi твоему и протоколу обмена с инициатором
SP>> запроса.
DR> А почему бы не унифицировать обмен через веб-форму и через
DR> приложение?
Он унифицирован полностью. Почувствуй разницу между интерфейсом с пользователем и с сервером. Первый может быть любым, хоть с капчей, хоть с блэкджеком. А во второй это всё тащить смысла нет. Тут всё должно быть максимально просто. Я рисков не вижу.
--
Best regards!
Posted using Hotdoged on Android
--- Hotdoged/2.10/Android
* Origin: Android device, Milky Way (2:5020/2141.3)
|
