hidden поля в случае get формы вполне себе попадают в URL. Если в первой форме будет пункт «Вам есть 18 лет», то у второй формы будет URL /form/2?is_18=true
Так что тут тоже как подойти…
Т.е. есть у меня 3-х этапная огромная веб-форма. Я заполнил первый этап, второй этап, начал заполнять третий — последний, и тут… Админ решил, что неплохо бы нам отмасштабироваться, включил новый сервер и прибил мою сессию на сервере. И что мне теперь — заново форму заполнять? (В случае stateless промежуточные состояния сохраняются в hidden поле или в БД).
Если же промежуточные состояния формы не держатся в памяти а скидываются в БД то какой-же это statefull?
Выборка с 06:50:00 по 06:50:19 (20 секунд) GET запросов к "/api/*"
А со счётчиками проблема в том, что нет гибкости. Захотели вы сделать выборку не за 20 секунд, а за 120 и уже нужно лезть в конфиги nginx, делать релоад, ждать накопления данных.
Не представляю какое преимущество может дать redis для анализа логов. Если какие-то счётчики держать, то ещё можно понять, но целиком логи очевидно удобнее и надёжнее в файл или какую-то систему аггрегации логов (syslog / logstash etc)
ASN.1 вон вообще в 84 году сделали. Другой вопрос, что и protocol buffers и thrift и ASN.1 могут кодировать только сообщения в своём собственном формате. Произвольный формат пакета ты им не закодируешь. А тут просто DSL для написания бинарных кодеков. Сравнивать его с protobuf etc не совсем корректно.
Ну хз, по-моему с натягом это можно «отказом дизайна» назвать. Основная суть претензии в том, что одна из реализаций клиента загружала данные из интернета без спроса. Сам протокол тут никак не скомпрометирован.
Так можно скатиться в, «вот смотрите, алиса отправляет бобу ссылку http://nsa.gov/UniqIdentifier123654 боб щелкает по ссылке… Опа, пативен уже подъехал».
Спасибо, да, мне тоже так кажется, просто пока не придумал как это лучше оформить. Возможно есть смысл подсказки в принципе вниз перенести, под входящие. Либо, как во многих сервисах делают, отображать во входящих «приветственное письмо» (хотя мне такая практика не очень нравится).
Ну и прорекламирую заодно уж свой сервис временной почты. Если письмо сразу не приходит — включайте пересылку — придёт на ваш реальный email, когда их сервер прочухается.
>Случайным
>base64(login:password)
>login:md5(password)
Да вы издеваетесь что ли?
В чём идея то? Если в том, чтобы пользователь не пытался запомнить содержимое файла, то base64 вполне достаточно, т.к. превращает «человекозапоминаемый» текст в условно-беспорядочную последовательность букв
echo -n "123456" | base64
MTIzNDU2
Секретным ключем можно только расшифровывать и подписывать информацию.
Вообще, зачем придумывать велосипедные сложности (ухудшающие безопасность) в простой концепции аутентификации по фактору «то, чем обладает пользователь»?
Пожалуй во фразе [по фактору «то, чем обладает пользователь»] смысл есть. Но объясните мне, как это снижает безопасность то и чем повышает сложность?
В топике, опять же, речь идёт в первую очередь не о безопасности а об удобстве.
Содержимосе ключевого файла должно быть случайным и незапоминаемым.
Ну ок, пусть base64(login:password) или, если совсем паранойя, то зашифрованное сервером (обратимо, с помощью секретного ключа) значение rsa.encrypt(login:md5(password), SecretKey).
Но заводить под это отдельную таблицу в БД? Ну нахрен… Бессмысленно.
Второй аргумент как то неубедительно звучит.
Окончательно валидировать форму можно на последнем этапе. Не думаю, что вопрос безопасности тут уместен.
/form/2?is_18=true
Так что тут тоже как подойти…
Если же промежуточные состояния формы не держатся в памяти а скидываются в БД то какой-же это statefull?
Выборка с 06:50:00 по 06:50:19 (20 секунд) GET запросов к "/api/*"
А со счётчиками проблема в том, что нет гибкости. Захотели вы сделать выборку не за 20 секунд, а за 120 и уже нужно лезть в конфиги nginx, делать релоад, ждать накопления данных.
Но думаю результат не сильно изменится.
Так можно скатиться в, «вот смотрите, алиса отправляет бобу ссылку
http://nsa.gov/UniqIdentifier123654
боб щелкает по ссылке… Опа, пативен уже подъехал».emails.skype.com/r/r?2.1.3OM.2x5.7GagfK.ECs%2aom..N.Dt2E.330.bW89MSZyc19lZT1ZV1poZEc5MmNXaHFaM0Z0UUdSeWIzQnRZV2xzTG0xbCZyc19vYz1OJnJzX2J2PUgmcnNfbXY9SCZyc19reT03R2FnZks%5fDcDANWF0
emails.skype.com/r/r?2.1.3OM.2x5.7GZ6bO.ECt%5feK..N.Dt2e.332.bW89MSZyc19lZT1kMko1ZFcxaFFERXdiV0ZwYkM1dmNtY18mcnNfb2M9TiZyc19idj1IJnJzX212PUgmcnNfa3k9N0daNmJPBMUYMVc0
Ну и прорекламирую заодно уж свой сервис временной почты. Если письмо сразу не приходит — включайте пересылку — придёт на ваш реальный email, когда их сервер прочухается.
echo -n "123456" | base64 MTIzNDU2
Вот так новость… www.openssl.org/docs/crypto/rsa.html
Хотя конечно ассиметричное шифрование в данном случае это оверкилл, можно обойтись и симметричным (DES / RC4).
Так то может и колонки хватит, но в топике предлагают именно что таблицу (один ко многим)
github.com/aruseni/fileauth/blob/master/fileauth/models.py
Пожалуй во фразе [по фактору «то, чем обладает пользователь»] смысл есть. Но объясните мне, как это снижает безопасность то и чем повышает сложность?
В топике, опять же, речь идёт в первую очередь не о безопасности а об удобстве.
Ну ок, пусть
base64(login:password)
или, если совсем паранойя, то зашифрованное сервером (обратимо, с помощью секретного ключа) значениеrsa.encrypt(login:md5(password), SecretKey)
.Но заводить под это отдельную таблицу в БД? Ну нахрен… Бессмысленно.
логин:пароль
? Нафига какая-то отдельная таблица в БД, какие-то дополнитьельные хеши, скрытые поля?