Oauth回调问题
我正在使用 OAuth 和 google data api。我们有一个仅供授权用户使用的门户。因此，当用户登录并访问日历页面时，系统会询问他们是否要将日历与谷歌日历同步。如果是，他们将被重定向以进行身份验证。用户授予访问权限后，Google 会将 OAuth_Token 附加到回调 URL。回调URL为portal日历页面的回调URL。此 url 的查询字符串选项已加密。但是当重定向发生时，它会返回到 url 的登录页面。
url 就像查询的 http://aaa.xyz.com/(encrypted 部分) string)，oauth_token授权后，该url变为
http://aaa.xyz .com/（查询字符串的加密部分）&oauth_token。因此，用户在重定向后看到的是登录页面，而不是原始页面。我应该如何在代码中处理这个问题。
I am using OAuth with google data api. We have a portal only for authorized users. So when users are logged in and if they are accessing calendar page, they will be asked if they want to sync their calendars with google calendar. If yes, they will be redirected for authentication. Once user has granted access, google appends OAuth_Token to the callback URL. the callback URL was that of the page of calendar in portal. This url has its query string options encrypted. But when the redirection happens , it takes back to login page of url.
url is like http://aaa.xyz.com/(encrypted part of query string) and after oauth_token is authorized, this url becomes
http://aaa.xyz.com/(encrypted part of query string)&oauth_token. So the user sees the login page after redirection instead of original page. How should I handle this in code.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当用户登录到您的站点时，请确保用户会话“状态”存储在会话中，以便当从 Google OAuth 的重定向返回到页面时，您检查是否在会议。如果是，则返回到用户访问的最后一个页面，否则转到登录。
这就是我在为银行站点实施 SSO 时所做的事情。
When a user logs in to your site, make sure that the user session "state" is stored in the session, so that when the redirection from Google OAuth returns back to the page, you check if the user "state" is found in the session. If it is, return to last page user visited, else goto login.
That's what I have done when I implemented SSO for a banking site.
您始终可以使用带外 OAuth，传递 oauth_callback='oob'。
这将不会重定向到您的页面，但会显示验证程序，以便用户可以将其复制/粘贴到您的应用程序中。
这对于您的用户来说比较麻烦，但如果访问令牌过期足够长的时间，情况也不会那么糟糕。
You can always use Out of Band OAuth, passing oauth_callback='oob'.
That will make no redirects to your page but show the verifier so the user can copy/paste it in your app.
This is more cumbersome for your users, but if the access tokens expire long enough, it won't be that bad.