限制 Google 帐户中用户的单个会话
是否有可能强制谷歌只为单个用户创建一个会话？
我在 GAE 中创建了服务，它使用 google id 来验证用户身份。 现在，单个用户可以通过共享从多台 PC 创建多个会话 他的用户名/密码。我想限制这个。
用简单的语言来说，成功登录后，应用程序应该注销所有其他 该用户的会话。
在 Gmail 中，页面底部有一个名为“上次活动详细信息”的链接。 单击详细信息后，它会显示当前会话，并提供注销其他会话的选项 会议。我想要以编程方式实现相同的功能。
还有一种选择：登录前检测用户是否已经登录 在？
查看此
http://mail。 google.com/support/bin/answer.py?ctx=%67mail&answer=45938
请参阅并发会话
如果可以以某种方式访问此信息，我可以采取适当的操作。
Is it possible to force google to create only one session for a single user?
I have created services in GAE, that uses google id to authenticate users.
Now a single user creating multiple sessions from multiple PCs by sharing
his username/password. I want to restrict this.
In simple language after successful login the application should sign out all other
session for this user.
In gmail there is a link at the bottom of the page by the name last activity details.
On clicking details it shows current sessions and also give option to log out other
session. I want same functionality programmatically.
There is one more option: before logging in detect whether the user is already logged
on?
Have a look at this
http://mail.google.com/support/bin/answer.py?ctx=%67mail&answer=45938
see Concurrent sessions
If this information can be accessed somehow I can take appropriate action.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这当然是可能的。
如果您使用 Google 帐户进行身份验证，则用户通过将其凭据发布到 Google 来登录，然后 Google 将身份验证令牌返回到您的网站，然后将该令牌作为 cookie 存储在用户的浏览器中。在 cookie 过期（默认为 24 小时）或用户注销之前，令牌一直有效。
如果您想跟踪多个登录会话，您可以编写设计为在登录或注销后运行的处理程序。如果您正常的登录后返回 URL 是“/do_stuff”，您可以将其更改为“/finish_login?next=%2Fdo_stuff”。在该处理程序中，您可以在代表会话的数据存储区中创建一个实体，并引用 Google 帐户、登录的 IP 地址和登录时间戳（当前时间戳）。您可以将会话实体密钥写入用户浏览器中的另一个 cookie。完成后，重定向到“下一个”URL。
注销后，您可以使用类似的处理程序来检查会话实体密钥 cookie、删除实体并删除 cookie。
如果您想向用户显示他们已从多个位置登录，请查询与其 Google 帐户关联的会话实体，该会话实体的历史时间少于 24 小时（或您的 Cookie 过期设置）。
如果您想远程注销另一个会话，您可能需要编写 Google 在 webapp.util 中提供的您自己的 login_required 装饰器版本。您的版本需要验证用户是否已登录，验证是否发送了会话密钥 cookie，并验证关联的实体是否仍然存在并且由正确的帐户拥有。
It's certainly possible.
If you're using Google Accounts for authentication, a user logs in by posting their credentials to Google, and Google returns an authentication token to your site which is then stored as a cookie in the user's browser. The token is good until the cookie expires (24 hours by default) or until the user logs out.
If you want to track multiple login sessions, you can write handlers designed to run after login or logout. If your normal post-login return URL is "/do_stuff", you might change this to "/finish_login?next=%2Fdo_stuff". In that handler you could create an entity in the datastore representing the session, with a reference to the Google Account, the IP address that logged in, and the login timestamp (current timestamp). You can write the session entity key to another cookie in the user's browser. After you're done, redirect to the "next" URL.
After logout you can have a similar handler that checks for the session entity key cookie, deletes the entity, and deletes the cookie.
If you want to show the user that they are logged in from multiple locations, query for session entities associated with their Google Account that are less than 24 hours old (or whatever your cookie expiration is set to).
If you want to remotely log out another session, you might need to write your own version of the login_required decorator that Google offers in webapp.util. Your version would need to verify that the user is logged in, verify that sent a session key cookie, and verify that the associated entity still exists and is owned by the correct account.
没有什么可以阻止您在 Google App Engine 数据服务中存储登录详细信息。
因此，您可以将用户的所有登录详细信息存储在其关联对象中。因此，我想说 GAE 和传统的 Web 应用程序之间没有区别 - 除了您将登录信息存储在数据库中，而不是让您的 Web 前端处理它。
There is nothing that prevents you from storing login details in Google App Engine Data service.
As a consequence, you can store all login details for a user in its associated object. As a consequence, I would say there is no difference between GAE and a traditionnal web application - excepted that you'll store login infos in database, instead of letting your web front-end handle it.