Леонид Каганов: дневник

Давайте я изложу свои рассуждения, а может кто-то что-то умное скажет.

1. Авторизация — способ общаться с друзьями и отсекать вредителей. Проблема авторизации и идентификации — самая муторная и сложная, потому что авторизация всегда и у всех слетает. Нет такого сайта с авторизацией, на котором бы не приходилось время от времени перелогиниваться.

2. В современном интернете единственная возможность идентифицировать пользователя — это данные, которые он сам предъявит. IP могут быть динамическими или корпоративными, строки браузеров однотипны и подделываемы. Единственный способ идентификации — хранить на стороне посетителя нечто вроде пароля.

3. На данный момент нам (мне) известны всего три технологии хранения данных на стороне клиента. Но среди них нет ни одной, которая бы гарантированно работала у любого пользователя — даже куки могут быть отключены по разным причинам. Итак, три метода хранения данных:

а) Куки. Устанавливаются сервером (или Javascript), предъявляются серверу при запросе страницы. Поэтому могут применяться там, где даже отключен Javascript.

б) Macromedia Flash (jog.swf). Устанавливаются и читаются на стороне пользователя через Javascript. Не работают в момент загрузки страницы — требует секунду, пока запустится инициализация от загруженного swf, но эта проблема мизерная. Плюсы: такая авторизация часто единая для всех браузеров клиента — залогинившись в одном, можно получить авторизацию и во всех остальных, что прекрасно.

в) Браузерные хранилища. Устанавливаются и читаются на стороне пользователя через Javascript. Работают только в браузерах последнего поколения.

Если вам известен какой-то еще метод — расскажите. Может, Javascript сумеет своими средствами собрать более уникальную информацию о системе — время установки, ID винчестера, установленные плагины и их номера? Может, JAVA сумеет запуститься тихо и без отжора ресурсов и что-то свое сохранить? Может, сервер на уровне Апача способен что-то узнать, анализируя информацию, какой файл у пользователя уже был закэширован? Не знаю.

4. Соответственно модель идеальной авторизации мне видится следующей:

— В момент запроса страницы сервер пытается прочесть куку (идентификатор посетителя). Если кука была 0 — выдает новый номер. Если куки не было, устанавливает куку = 0. В любом случае отдает страницу, в коде которой кука также присутствует. Дальше действует скрипт на машине клиента.

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

— Если кука в теле страницы не 0, а в остальных хранилищах ничего нет — записать ее во все хранилища (включая куки).

— Если кука не 0, но в хранилищах обнаружена другая версия — считать правильной ее и использовать ее. Продублировать везде, где возможно. Сообщить серверу аяксом, что он погорячился, выдавая новую куку, ведь есть старая. (Если бы сервер хотел заменить куку, он бы выдал страницу с инструкциями, меняющими куку во всех хранилищах сразу.)

Такая модель позволит сохранять авторизацию в большинстве случаев, включая случаи, когда отключен Javascrit, но куки работают. А также наоборот: когда куки почему-то выключены, но Javascript и какое-то из двух других хранилищ работает.