Twitter APIの認証に失敗するブラウザでCORSのプリフライトが発生する

Question

ブラウザでTwitter APIを呼び出すために、3-legged authorizationを実行する必要があります。このプロセスは、署名された要求を/oauth/request_tokenにポストすることによって要求トークンを取得することから始まります（sign in with Twitterの開始方法も同様です）。

私の問題は、ブラウザがTwitter APIエンドポイントにPOSTする前に、OPTIONSメソッドを使用してpreflight the requestにすることです。このプリフライトリクエストは常にステータス400（Bad Request）を返します。ここで

は、あなたが取得APIサポートするブラウザコンソールにカット＆ペーストができることを例です：

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 

：Chromeで

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' }); 

を、プリフライトリクエストは、この（Firefoxが似ている）のように見えます

そして、プリフライト応答は次のようになります。

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 -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://api.twitter.com/oauth/request_tokenに成功したCORSのプリフライトを行うようになる何をしないのですか？

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を見つけました。