Python-сообщество

yanka
автодополнение юролов SID, всегда считалось крайним случаем, но он должен предусматриваться программистом

Я готов потерять N процентов идиотов, вместо получения претензий от этих идиотов за потерянные деньги с аккаунтов.
Я не готов соглашаться, что идиоты ради удобства имеют право ставить себе пароли типа “god”, “sex”, “love”, “123”.
Я не согласен, что отпечаток NATовсого IP и достаточно неуникальных User-Agent - хоть что-то гарантирует, и уверен, что пользователям неприятно ловить частые вылеты на динамических IP.

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

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

yanka
Механизм сессий не должен зависеть от настроек клиента

А в приличных заведениях почему-то дресс-код и фейс-контроль, но никого это почему-то не смущает.
И даже в троллейбусе “проездной” требуют предъявить и никого не беспокоит, что ты его не носишь, чтобы не потерять.

Отредактировано (Дек. 11, 2010 22:11:39)

zheromo
Дайджест авторизацию еще никто не отменял - и включена она в каждом браузере, и отключить ее не получится.

Базовая и дайджест аутентификации не являются прямой альтернативой механизму сеансов, к сожалению.
Также этот метод имеет определённые недостатки: нельзя принудительно завершить сеанс со стороны сервера - по таймауту неактивности или команде пользователя. Этот недостаток особо актуален для активных сёрферов открывающих over 9000 вкладок, что усугубляет неочевидность необходимости закрыть ВЕСЬ браузер, а не только вкладку или окно. Впрочем, возможно в последнее время что-то и поменялось - я давно не встречал сайтов реализующих аутентификацию подобным образом, надо будет протестировать.

Сделал механизм сессий на beaker довольно удобно но сохранить его в Couchdb так и не получилось. То есть я нашёл пару классов которые этим занимаются но почему то их использование показалось мне не очевидным. А чтоб просто взять и сохранить насколько я понял надо как то конвертировать объект с данными сессии в удобоваримый couchdb.

yanka
А ты , ничего более о себе серверу не сообщил? И у тебя теперь только один безликий SID? А твой IP, а клиент, а операционная система, я могу список продолжить. В сущности это твои отпечатки пальцев, которые помогут серверу в дальнейшем проигнорировать украденный SID

Дано: Организация сидит за NAT. Клиент и операционная система определены корпоративной политикой. Ваши действия?

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

Отредактировано (Дек. 12, 2010 10:11:42)

yanka
Я  не понимаю, при чем тут пхп? Это что своего рода снобизм?

Это я к тому, что упомянутая тобой 20%, цифра бредовая.
Я и в один процент обескукенных пользователей не поверю…

blessmaster
Базовая и дайджест аутентификации не являются прямой альтернативой механизму сеансов, к сожалению.
Также этот метод имеет определённые недостатки: нельзя принудительно завершить сеанс со стороны сервера - по таймауту неактивности или команде пользователя.

Логин пользователя воспринимаем как сид - и получаем полный аналог сессий.

Сеанс можно спокойно завершить сказав браузеру - НЕ АВТОРИЗОВАН или сделать редирект на страницу - не требующей авторизации - или просто убрать пользователя из списка вошедших - если захочет залогинится еще раз.

Основной минус - окошко плохо вписывается в дизайн - а так великолепный, на мой взгляд, метод

zheromo
Логин пользователя воспринимаем как сид - и получаем полный аналог сессий.

Сеанс можно спокойно завершить сказав браузеру - НЕ АВТОРИЗОВАН или сделать редирект на страницу - не требующей авторизации - или просто убрать пользователя из списка вошедших - если захочет залогинится еще раз.

Основной минус - окошко плохо вписывается в дизайн - а так великолепный, на мой взгляд, метод

Сессия может быть без логина - в этом коренное отличие. Я могу залогиниться одним пользователем, выполнить определённые действия, разлогиниться и залогиниться другим - оставаясь в одной сессии. При этом один пользователь в свою очередь может иметь несколько независимых сессий. Ещё одна возможность - многодоменная сессия, вроде того же ЖЖ (или это возможно сделать в HTTP-авторизации?).

- “сказав браузеру - НЕ АВТОРИЗОВАН” - сценарий действий, если тот же пользователь хочет заново войти на эту страницу? Сколько раз я должен сказать “не авторизован”, если у пользователя может быть открыто произвольное количество вкладок? Я должен выбросить пользователя из всех браузеров, если он вышел только в одном?
- “сделать редирект на страницу, не требующую авторизации” - что будет, если через некоторое время другой человек не закрывая браузер зайдёт на страницу требующую авторизации?
- “убрать пользователя из списка вошедших” - что имеется в виду? Вариант с “выбросить из всех браузеров”?

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

ZZZ
Это я к тому, что упомянутая тобой 20%, цифра бредовая.
Я и в один процент обескукенных пользователей не поверю…

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

Отредактировано (Дек. 12, 2010 21:55:18)

Я не думаю, что число ботов сопоставимо с числом пользователей (кстати, по контексту речь была именно о последних).
Вообще, в подобного рода спорах надо обращаться к статистике, которой у меня, увы, нет. Было бы интересно, если бы кто-нить поделился ссылочкой в нужном направлении.