GitHub OAuth授权请求不会重定向到“授权应用程序"页面 [英] GitHub OAuth authorize request doesn't redirect to Authorize Application page

问题描述

我已经实现了自己的类，用于使用Ruby中的Faraday通过OAuth处理到GitHub的授权.我已经验证了以下情况:

I've implemented my own classes for handling authorization via OAuth to GitHub using Faraday in Ruby. I've verified that under the following conditions:

• 未登录GitHub
• 该应用程序不存在令牌

使用随机state变量通过GET到"/login/oauth/authorize"的授权请求:

that a request for authorization via GET to "/login/oauth/authorize" with a random state variable:

• 重定向到GitHub登录页面
• 登录后重定向到授权应用程序"页面
• 授权后使用临时代码对我的应用执行回调
• 当我用临时代码POST到"/login/oauth/access_token"时，用access_token响应

• Redirects to the GitHub login page
• Redirects to the Authorize Application page after login
• Executes callback to my app with temporary code after authorizing
• Responds with access_token when I POST to "/login/oauth/access_token" with temporary code

我遇到的问题是，当我更改第一个条件时，我尚未登录GitHub.将相同的GET请求发送到GitHub，我看到带有正确参数的正确URL.然后，我看到使用return_to参数看似是GitHub的正确重定向，但是它很快又再次重定向回GitHub主页.

The problem I have is when I alter the first condition, I'm not already logged into GitHub. The same GET request is sent to GitHub, I see the correct URL with the right parameters. I then see what appears to be the correct redirect by GitHub with a return_to parameter, but it quickly just redirects again back to the GitHub home page.

我希望这很容易，例如忘记标题参数之类的东西，并且有人可能会立即发现问题.无论如何，我们将不胜感激...

I'm hoping it's something easy like forgetting a header parameter or something, and someone might spot the problem right away. Anyway, any help is appreciated...

设置法拉第连接的代码:

Code to setup Faraday connection:

def connection
  @connection ||= Faraday.new(url: 'https://github.com') do |faraday|
    faraday.request  :url_encoded
    faraday.response :logger
    faraday.adapter  Faraday.default_adapter
  end
end

发送授权请求的代码:

def request_authorization(client_id, redirect_uri, redirect_id, scope, expected_state)
  response = connection.get '/login/oauth/authorize', {
    client_id: client_id,
    redirect_uri: "#{redirect_uri}?id=#{redirect_id}",
    scope: scope,
    state: expected_state
  }

  if response.status == 302
    response.headers[:location]
  else
    nil
  end
end

我没有显示代码，但是我的控制器将重定向到request_authorization()的URL答复.同样，在这两种情况下，我都绝对可以看到从控制器进行的重定向，但是第二种情况似乎遇到了GitHub在重定向请求中不喜欢的东西.我认为它然后会重定向到主页，并且由于我的原始请求中存在未知问题，因此从不回复我的应用.

I didn't show the code, but my controller does a redirect to the URL reply from request_authorization(). Again, I definitely see the redirect from my controller in both cases, but the second case seems to encounter something GitHub didn't like in the redirected request. I assume it then redirects to the home page and never replies to my app because of this unknown problem in my original request.

谢谢， 大卫

推荐答案

Ivan为找到我的问题的答案提供了很大的帮助.我已经假设问题是使用Faraday或OAuth的一些细节，但事实证明，问题是被证明是错误的基本假设.希望这会帮助其他遇到类似误会的人.

Ivan from GitHub was a great help in finding the answer to my question. I had assumed the problem was some detail with using Faraday or OAuth, but it turns out the problem was a basic assumption that proved wrong. Hopefully this will help others that run into a similar misunderstanding.

我假设我的应用程序用户想要连接到GitHub(或其他OAuth服务)，则会向我的应用程序发出类似连接"的请求.然后，我的应用程序将向GitHub生成OAuth授权请求，处理所有重定向，并最终向用户展示授权应用程序"页面以供接受.

I had assumed that a user of my app that wanted to connect to GitHub (or another OAuth service) would issue something like a "connect" request to my app. My app would then generate the OAuth authorization request to GitHub, handle any redirects, and eventually wind up presenting the Authorize App page to the user for acceptance.

结果证明，我实际上只需要向连接"请求发出直接向GitHub发出授权请求的链接.然后，我的应用程序只需要担心已经完成了处理回调.现在更容易使用，并且可以在所有情况下使用.

Turns out I just needed to make the "connect" request actually a link to directly make the authorization request to GitHub. My app then only has to worry about handling the callback, which it already did. Easier and works in all cases now.

由于这种情况很简单，因此在未登录时发现了错误的方法.登录失败，因为我没有处理浏览器通常会提供的会话状态.

Turns out the wrong approach worked when not logged in due to it being the simple case. It failed when logged in because I wasn't handling session state that normally the browser would provide.

更仔细地阅读OAuth RFC可以消除我对在哪里处理用户代理和客户端的请求和响应的困惑.

A more careful read of the OAuth RFC cleared up my confusion about where requests and responses are handled for the User Agent and for the Client.

这篇关于GitHub OAuth授权请求不会重定向到“授权应用程序"页面的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！