0
<< предыдущая заметкаследующая заметка >>
30 декабря 2009
Задолбался вчера с openid

Но вроде настроил — будет работать лучше, чем раньше. Единственная проблема — самая лучшая (по экспериментам) библиотека openid имеет неприятное свойство: подтвердить openid ты можешь, но когда клиент вернется на твою страницу успешно подтвержденным, ты никогда не узнаешь, КАКОЙ OPЕNID ТЫ ПРОВЕРЯЛ. в старом дневнике я встраивал его в адрес возврата, и глючили вордпрессы. Теперь решил сохранять в куках. Но это дыра в безопасности: злоумышленник может попытаться проверить dr-livsey.livejournal.com (безуспешно), но полученную куку (пусть и хэшированную) запомнит и подставит при проверке vasyapupkin.pomoika.com, и система сочтет его dr-livsey. Решения пока не придумал. это одна из причин, почему раздел авторизации готов, но закрыт.

Причина вторая — сложность алгоритма. Каждый пользователь, зашедший второй раз и умеющий сохранять куки, получает номер в базе. После чего он может а) заполнить свою анкетку и пользоваться этим номером дальше, б) ввести свой прежний логин/пароль или openid и вернуть себе законный (утерянный) номер. Логично будет при этом-нынешний считать "временным" и стереть. Но перед тем логично пройти по базе голосований, комментариев и проч, и если он с временного номера успел где-то наследить, то проставить в этих базах номер старый, поскольку стало понятно, что это один человек, и все его деяния надо обобщить. Ну, чтобы я мог нажать кнопочку "все комментарии, оставленные этим человеком" и видеть все. Логично? Идем далее. Ну а если человек не спешил логиниться старым логином, а использовал временный долго, обжил его,-прописал пароли, прошел openid-авторизацию, а теперь вспомнил старый пароль и решил перелогиниться старым номером? В общем, на этом вчера мысль остановилась, и я пошел спать.

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
архив понравившихся мне ссылок
Оставить комментарий
Windows Opera
0
0
batc0h
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Вообще такие вопросы решаются либо средствами БД (foreign on delete/on update), либо делаются через таски. В вашем случае (если не ошибаюсь MySQL и движок MyISAM) - релейшены невозможны, переходить на InnoDB также особого смысла нет - уменьшится скорость работы БД, на PostgreSQL вы тоже врядли станете мигрировать. Поэтому логичнее сделать через простую таблицу, куда будут записываться идентификаторы для слияния, что-нибудь типа user_root_id | user_temp_id, поскольку такая операция очень дешевая и выполнится в базу мгновенно. А далее, скрипт по крону запускается периодически, проверяет наличие в этой таблице свежих записей и выполняет комплекс апдейтов в других таблицах, меняя там айдишники, каунты (если вы их кешируете) и прочую муть.
Вообще, очень надеюсь, что после НГ смогу выделить некоторое количество времени и ознакомиться подробно с существующим скриптом и структурой БД, возможно смогу подсказать какие-нибудь улучшения в плане повышения производительности, умного кеширования etc.
whois*: title='{#countryname}
Чертаново{Россия'> {city:|:{#countryname}|*:Чертаново{Россия|}}
0
0
LLeo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
,О, это было бы здорово (советы по производжительности).

Но зачем слияние по крону? Слияние - редчайшая операция, она происходит, когда пользователь перерегистрируется. Это само по себе крайне редкое событие. Почему не делать в реальном времени?
Linux
0
0
batc0h
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Очень странно по нескольким причинам

1) При авторизации может быть серия редиректов и по стандарту они должны резолвиться (т.е. конечная openid строка — это которая содержит <link rel="openid.delegate"> или <link rel="openid2.provider">)

т.е. если я укажу myname.freedns.loc, который отошлёт (http-кодами 301 или 302) на mynewname.loc, а тот на www.mynewname.loc, именно последнее мы и должны рассматривать как ID

2) в openid2 вообще вводимая для логина ссылка и результирующий id не связаны, id возвращается сервером при аутентификации.

например, всем пользователям гугла надо вводить https://www.google.com/accounts/o8/id как url авторизации, а система уже вернёт конкретнуюю строку на конкретный профиль https://www.google.com/accounts/o8/id?id=блаблабламногабукв

так что либо ваш плагин нуждается в очень серьёзной доработке, либо ищите вариант лучше. (кстати, можно попробовать открутить от вордпрессовского плагина — он там же GPL)
whois*: title='{#countryname}
Чертаново{Россия'> {city:|:{#countryname}|*:Чертаново{Россия|}}
0
0
LLeo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Я не умею. Вы можете открутить openid-плагин в отдельный скрипт php и сделать демку?
Linux
0
0
batc0h
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
не факт, но я попробую
whois*: title='{#countryname}
Чертаново{Россия'> {city:|:{#countryname}|*:Чертаново{Россия|}}
0
0
LLeo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Ура!!!
Windows Opera
0
0
batc0h
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Ну, я исходил из описания задачи :) Вам виднее, нужен в данном случае крон или нет. Но если например человек год ходил под временным логином, а потом вдруг взял да залогинился под старым - прикиньте, какое количество записей нужно апдейтнуть в разных таблицах для слияния идентификаторов. Если это действительно редкое явление - можно и забить. Но если во время активного наплыва народа на блог пара десятков таких индивидов захотят одновременно таким образом залогиниться - база ляжет. Я придерживаюсь правила, согласно которому любые пакетные изменения в базе, начиная с пары десятков записей, следует делать не напрямую при запросе клиента, а через очередь. В первую очередь чтобы клиент не ждал результат (особенно если он ему прямо сейчас не нужен), а получил страницу максимально быстро. Ну и чтобы нагрузка на базы была равномерной (нагрузкой в очереди гораздо проще управлять).
Windows Opera
0
0
batc0h
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Оказывается, не зря меня смущал календарь.
Только что обратил внимание: в основном дневнике в календаре квадратиком выделяется дата открытой заметки, а в тестовом текущая дата.
ИМХО, там удобней.
Linux
whois*: title='{#countryname}
Чертаново{Россия'> {city:|:{#countryname}|*:Чертаново{Россия|}}
0
0
LLeo
Этот человек не загрузил свой юзерпик, и я подобрал ему этот. Человек, пишущий такое, должен именно так выглядеть, верно?
Как удобней?
<< предыдущая заметка следующая заметка >>


Include not found: `/home/www/lleo.me/blog/template/_reklamnaya_lirica.htm`