Twitter API 授权在浏览器中的 CORS 预检失败 [英] Twitter API authorization fails CORS preflight in browser

问题描述

我正在尝试执行调用 Twitter 所需的三腿授权浏览器中的 API.该过程首先通过将签名请求发布到 /oauth 来获取请求令牌/request_token(这也是使用 Twitter 登录的方式a> 开始).

I'm trying to do the 3-legged authorization necessary to call the Twitter APIs in a browser. The process starts with getting a request token by POSTing a signed request to /oauth/request_token (this is also how sign in with Twitter begins).

我的问题是，在浏览器将 POST 到 Twitter API 端点之前，它想要使用 OPTIONS 方法预检请求.此预检请求始终返回状态 400(错误请求).

My problem is that before the browser will POST to the Twitter API endpoint, it wants to preflight the request with an OPTIONS method. This preflight request is always returning status 400 (Bad Request).

以下是一个示例，您可以将其剪切并粘贴到支持 Fetch API 的浏览器控制台中:

Here's an example that you can cut and paste into a browser console that supports the Fetch API:

fetch('https://api.twitter.com/oauth/request_token', { method: 'POST', mode: 'cors', headers: new Headers({ authorization: 'xxx' }), body: 'oauth_callback=http%3A%2F%2Flocalhost%2F' });

在 Chrome 上，预检请求如下所示(Firefox 类似):

On Chrome, the preflight request looks like this (Firefox is similar):

OPTIONS /oauth/request_token HTTP/1.1
accept:*/*
accept-encoding:gzip, deflate, sdch
accept-language:en-US,en;q=0.8
access-control-request-headers:authorization, content-type
access-control-request-method:POST
cache-control:no-cache
origin:null
pragma:no-cache
user-agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

预检响应如下所示:

HTTP/1.1 400 Bad Request
content-length: 0
date: Tue, 08 Mar 2016 22:21:37 GMT
server: tsa_a
x-connection-hash: 529e3d8338caeb980077637d86db5df1

请注意，问题是不是我没有在上面的示例中指定真正的授权标头.预检请求中未使用授权标头的值.

Note that problem is not that I didn't specify a real authorization header in the example above. The value of the authorization header is not used in the preflight request.

如果我将 POST 请求的组件打印到控制台并将这些部分组合成一个 curl 命令(不预检)，那么我可以获得一个请求令牌.但是，如果我尝试在 curl 中模拟预检请求，则无法使其正常工作:

If I print out the components of my POST request to the console and assemble the pieces into a curl command (which doesn't preflight) then I can get a request token. But if I try to simulate the preflight request in curl, I haven't been able to get that to work:

$ curl -v -X OPTIONS -H "access-control-request-headers:authorization,content-type" -H "access-control-request-method:POST" -H "origin:http://example.com" https://api.twitter.com/oauth/request_token
*   Trying 199.59.148.20...
* Connected to api.twitter.com (199.59.148.20) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*    subject: C=US; ST=CA; L=San Francisco; O=Twitter, Inc.; OU=Twitter Security; CN=api.twitter.com
*    start date: Aug 11 00:00:00 2015 GMT
*    expire date: Aug 15 12:00:00 2016 GMT
*    subjectAltName: api.twitter.com matched
*    issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*    SSL certificate verify ok.
> OPTIONS /oauth/request_token HTTP/1.1
> Host: api.twitter.com
> User-Agent: curl/7.47.1
> Accept: */*
> access-control-request-headers:authorization,content-type
> access-control-request-method:POST
> origin:http://example.com
> 
< HTTP/1.1 400 Bad Request
< content-length: 0
< date: Tue, 08 Mar 2016 23:06:44 GMT
< server: tsa_a
< x-connection-hash: 66174829ef6d3f5e5ec641ac080ad19c
< 
* Connection #0 to host api.twitter.com left intact

我错过了什么让我对 https 进行成功的 CORS 预检://api.twitter.com/oauth/request_token?

What am I missing that will let me do a successful CORS preflight to https://api.twitter.com/oauth/request_token?

推荐答案

所以令人不满意的解决方案似乎是 Twitter API 不支持 CORS.这对我来说似乎有点令人惊讶，因为这意味着无法在浏览器中使用该 API.

So the unsatisfying resolution appears to be that the Twitter API does not support CORS. This seems a little astonishing to me, as it means that the API cannot be used from a browser.

该政策决定可能与他们的 OAuth 实施有关，即 任何有权访问呼叫平台的人都容易受到攻击.也许这在 2010 年还可以，但大多数其他主要互联网公司已经想出了如何进行基于客户端的授权.

That policy decision is probably related to their OAuth implementation, which is vulnerable to anyone with access to the calling platform. Maybe that was okay back in 2010, but most of the other major internet players have figured out how to do client-based authorization.

这篇关于Twitter API 授权在浏览器中的 CORS 预检失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！