很抱歉,如果这是一个简单的问题。
我是LinkedIn的新手,我正在尝试完成OAuth 2.0流程,以便在获得https://developer.linkedin.com/documents/authentication所述的临时“授权码”后获取60天的“访问令牌”。
我对第3a部分没有任何问题 - 获取临时授权码。我只是将用户重定向到LinkedIn URL:
https://www.linkedin.com/uas/oauth2/authorization?response_type=code
&client_id=YOUR_API_KEY
&scope=SCOPE
&state=STATE
&redirect_uri=YOUR_REDIRECT_URI
在用户授予权限后,他们会被重定向回我的应用程序,并检查返回的参数以查看是否一切顺利,并根据文档检索临时身份验证代码作为返回的表单参数之一。< / p>
但是,我对如何继续执行步骤3b感到困惑 - 交换访问令牌的授权码(然后可以用来发出API请求)。我的困惑是因为即使是文档显示看起来似乎是带参数的典型GET URL,它旁边也会显示“POST”。所以我认为必须发出POST请求而不是GET。
但他们的意思是什么?为什么文档提供带有查询参数的URL,而不是详细说明所需的POST请求,URL以及如何在体内格式化参数?我基本上不确定如何形成我对第3b步的请求。
我假设我不能像使用3a网址那样简单地将用户重定向到3b网址,对吧?如果可以的话,这将很容易。
我使用的语言是服务器端JavaScript。我可以重定向。如果我知道所需的格式,我可以形成并发出POST请求。我可以创建GET请求。我只是不熟悉这种情况,说这个请求的文档应该是这样的:
https://www.linkedin.com/uas/oauth2/accessToken?grant_type=authorization_code
&code=AUTHORIZATION_CODE
&redirect_uri=YOUR_REDIRECT_URI
&client_id=YOUR_API_KEY
&client_secret=YOUR_SECRET_KEY
但同时表明它是一个POST请求。
是否有一些使用该URL的快捷方式来发出POST请求?或者我是否应该了解如何获取该URL并将其转换为典型的帖子请求并将所有参数放入正文并向https://www.linkedin.com/uas/oauth2/accessToken本身提出请求?
对不起,如果这是显而易见的事情。这不是我以前遇到的事情。
任何帮助都将不胜感激。
谢谢,
道格
答案 0 :(得分:8)
考虑作为教程,它会顺利地驱动你访问令牌:)
第1步:
写下这个,因为我将遵循相同的 我创建了一个文件夹“/ var / www / html / code”
第2步:
致电:
https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id= 输入您的client_id &amp; redirect_uri = http%3A%2F%2Flocalhost%2Fcode&amp; state = 987654321&amp; scope = r_basicprofile
回复:
你会得到不同的回复,但结构会相同。
第3步:
卷曲-X POST --http1.1 “https://www.linkedin.com/oauth/v2/accessToken” --cookie “X-CSRF令牌:987654321” -d“grant_type = authorization_code&安培;代码= AQTnRRDM_pMw6Nn8jutiCKTH3xmqHOPnVb4udfGI7KbK7mLhie2XqcEZf1IOycVdgGC5mamWEiFd3DxJznxJZYaix_UCGlIH_PbJJZG720LBk5heSrE&安培; REDIRECT_URI = HTTP%3A%2F% 2Flocalhost%2Fcode&amp; client_id = client_id &amp; client_secret = client_secret “ - H”内容类型:application / x-www-form-urlencoded“
答案 1 :(得分:2)
当遵循规范时,您应该在POST Content-Type
设置为application/x-www-form-urlencoded
的情况下发送参数,因此常规表单发布但事实证明LinkedIn还允许使用代码交换代码一个简单的GET,其中包含URL的查询部分中的参数,如示例所示。不建议(并且违反规范)使用GET作为参数最终日志,浏览器历史记录和GET更容易受到劫持攻击。
这是一条(编辑过的)GET到LinkedIn的CURL跟踪:
* Connected to www.linkedin.com (108.174.2.129) port 443 (#0)
...
> GET /uas/oauth2/accessToken?grant_type=authorization_code&code=<code>&redirect_uri=<url>&client_id=<id>&client_secret=<key> HTTP/1.1
> User-Agent: curl/7.39.0
> Host: www.linkedin.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Apache-Coyote/1.1
< P3P: CP="CAO CUR ADM DEV PSA PSD OUR"
< Content-Type: application/json;charset=UTF-8
< Content-Language: en-US
< Content-Length: 219
< Vary: Accept-Encoding
< Date: Wed, 31 Dec 2014 11:04:55 GMT
< X-FS-UUID: 5b7c888b35f0b413d05936cac02a0000
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Li-Fabric: PROD-ELA4
< Strict-Transport-Security: max-age=0
...
<
* Connection #0 to host www.linkedin.com left intact
{"access_token":"<>","expires_in":5178866}