Twitter API授權失敗瀏覽器中的CORS預檢

Question

我正在嘗試執行在瀏覽器中調用Twitter API所必需的3-legged authorization。該過程通過在/oauth/request_token上發佈簽名請求（這也是sign in with Twitter開始的方式）獲取請求令牌開始。

我的問題是，在瀏覽器發佈到Twitter API端點之前，它想要使用OPTIONS方法preflight the request。此預檢請求始終返回狀態400（錯誤請求）。

這裏，你可以剪切並粘貼到支持獲取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是相似的）：

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 

注意proble m是而不是，我沒有在上面的例子中指定一個真正的授權頭。預檢請求中未使用授權標頭的值。

如果我將POST請求的組件打印出來並將這些組件組裝成一個curl命令（不會預檢），那麼我可以得到一個請求令牌。但是，如果我嘗試模擬在捲曲預檢要求，我一直沒能得到那個工作：

$ 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 

我缺少什麼，讓我做一個成功的CORS預檢https://api.twitter.com/oauth/request_token？

Answer 1

所以不滿意的分辨率似乎是Twitter API does not support CORS。這對我來說似乎有點令人驚訝，因爲這意味着API不能在瀏覽器中使用。

該政策決定可能與其OAuth實施有關，即vulnerable to anyone with access to the calling platform。也許這在2010年還是可以的，但其他大多數互聯網玩家大多數都知道了how to do client-based authorization。