gpt4 book ai didi

twitter - Twitter API授权未能在浏览器中进行CORS预检

转载 作者:行者123 更新时间:2023-12-03 15:18:10 28 4
gpt4 key购买 nike

我正在尝试执行3-legged authorization来在浏览器中调用Twitter API。该过程首先通过将签名的请求发布到 /oauth/request_token 来获得请求 token (这也是sign in with Twitter的开始方式)。

我的问题是,在浏览器将POST到Twitter API终结点之前,它想使用OPTIONS方法preflight the request。该预检请求始终返回状态400(错误请求)。

这是一个示例,您可以将其剪切并粘贴到支持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相似):
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

请注意,问题不在于我没有在上面的示例中指定真正的授权 header 。授权 header 的值未在预检请求中使用。

如果我将POST请求的组件打印到控制台,然后将其组装成curl命令(不会预检),那么我可以获得请求 token 。但是,如果我尝试模拟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

我缺少什么让我对 https://api.twitter.com/oauth/request_token成功进行CORS预检?

最佳答案

因此,令人不满意的解决方案似乎是Twitter API does not support CORS。在我看来,这有点令人惊讶,因为这意味着无法在浏览器中使用该API。

该策略决策可能与其OAuth实现有关,即vulnerable to anyone with access to the calling platform。也许在2010年还可以,但是大多数其他主要的互联网公司都知道how to do client-based authorization

关于twitter - Twitter API授权未能在浏览器中进行CORS预检,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35879943/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com