Я использую OpenID. Как сделать так, чтобы пользователь долгое время оставался в системе даже после закрытия окна браузера?
Как мне сохранить и получить доступ к объекту пользователя User?
По сути, я просто не совсем понимаю, как сеансы работают в Java.
Итак, вы на самом деле хотите использовать опцию «Запомнить меня на этом компьютере»? На самом деле это не связано с частью OpenID. Вот независимый от языка способ, как вы можете это сделать:
Сначала создайте таблицу БД как минимум с cookie_id и user_id столбцами. При необходимости также добавьте cookie_ttl и ip_lock. Думаю, названия столбцов говорят сами за себя.
При первом входе в систему (если необходимо, только с установленным флажком «Запомнить меня») создайте длинный, уникальный, трудно угадываемый ключ (который никоим образом не связан с пользователю), который представляет cookie_id, и сохраните его в БД вместе с user_id. Сохраните cookie_id как значение файла cookie с известным именем файла cookie, например. remember. Дайте файлу cookie длительный срок службы, например. один год.
При каждом запросе проверяйте, вошел ли пользователь в систему. Если нет, проверьте значение файла cookie cookie_id, связанное с именем файла cookie remember. Если он есть и действителен в соответствии с БД, то автоматически войдите в систему пользователя, связанного с user_id, и снова отложите возраст файла cookie, а также, если есть, также cookie_ttl в БД.
В терминах Java/JSP/Servlet используйте HttpServletResponse#addCookie() для добавления файла cookie и HttpServletRequest#getCookies() для получения файлов cookie. Вы можете выполнить всю первоначальную проверку в Filter, который прослушивает нужные ресурсы, например. /* или, может быть, немного более ограниченным.
Что касается сессий, то здесь они не нужны. Он имеет более короткий срок службы, чем вам нужно. Используйте его только для размещения вошедшего в систему пользователя или найденного пользователя, когда у него есть действительный файл cookie remember. Таким образом, Filter может просто проверить свое присутствие в сеансе, и тогда ему не нужно каждый раз проверять файлы cookie.
В конце концов, это довольно прямолинейно. Удачи.
Ask Question здесь :)
- person BalusC; 02.02.2010
HttpSession (jsessionid), PHP $_SESSION (phpsessionid) и любых других конструкций сеанса, используемых другими веб-языками/фреймворками? Я просто явно сказал сгенерировать длинный, уникальный, трудно угадываемый ключ (который никоим образом не связан с пользователем). Легче захватить код, используемый для шифрования данных сеанса, и злоупотребить им (особенно если он распространяется и/или с открытым исходным кодом), чем угадать/захватить совершенно случайный ключ сеанса и злоупотребить им. Этот разозленный -1 от вас не имеет никакого смысла, но если вам от этого станет легче, будьте моим гостем :)
- person BalusC; 02.02.2010
cookie_ttl и ip_lock, которые я упомянул в своем ответе.
- person BalusC; 02.02.2010
cookie_ttl и ip_lock в прошлый раз, извините :) Хотя я бы не сказал, что они говорят сами за себя. Важно проверять эти два параметра каждый раз, когда пользователь аутентифицируется с помощью cookie_id (что вы не указали явно). Однако взломать распространенный алгоритм симметричного шифрования, такой как AES или Tripple-DES, как вы сказали, не проще, чем взломать ваш генератор случайных ключей. Кроме того, легче идентифицировать недопустимые значения, так как они приведут к тарабарщине после расшифровки. Незаконный cookie_id может быть просто устаревшим.
- person sfussenegger; 02.02.2010
Что ж, первоначальной причиной, по которой я выбрал OpenID, было то, что кто-то другой мог взять на себя большую часть реализации и безопасности аутентификации за меня.
При более подробном изучении OpenID выяснилось, что существует так называемый «немедленный запрос» (http://openid.net/specs/openid-authentication-2_0.html#anchor28).
При запросе аутентификации Проверяющая сторона МОЖЕТ потребовать, чтобы OP не взаимодействовал с конечным пользователем. В этом случае OP ДОЛЖЕН немедленно ответить либо утверждением об успешной аутентификации, либо ответом, указывающим, что запрос не может быть выполнен без дальнейшего взаимодействия с пользователем.
Из-за этого я думаю, что могу просто сохранить URL-адрес openID пользователя в файле cookie и использовать немедленный запрос, чтобы узнать, аутентифицирован ли пользователь или нет. Таким образом, мне не нужно ничего делать с моей базой данных или реализовывать какую-либо логику для предотвращения перехвата сеанса долгоживущего файла cookie.
Похоже, что этот метод предлагает сделать это OpenID с их проверяющей стороной. Передовой опыт.
