Well, that's what I've found so far.
Discogs made its API HTTPS only according to this thread.
I used Charles to analyze HTTP requests issued by Yate.
I'm not an OAuth pro, but it looks like a bug in Yate networking layer.
The first request is OK:
POST /oauth/request_token HTTP/1.1
Host api.discogs.com
Content-Length 0
Connection keep-alive
Accept */*
User-Agent Yate/3.11 +http://2manyrobots.com
Authorization OAuth realm="", oauth_consumer_key="<a key>", oauth_signature_method="HMAC-SHA1", oauth_signature="<a signature>", oauth_timestamp="<a timestamp>", oauth_nonce="<nonce>", oauth_version="1.0"
Accept-Language ru
Accept-Encoding gzip, deflate
The response is 302 Found:
HTTP/1.1 302 Found
Content-Type text/html
Content-length 0
Connection Close
Location https://api.discogs.com/oauth/request_token
Yate issues another request, but the verb is GET, not POST. Moreover, there aren't any OAuth headers anymore...
GET /oauth/request_token HTTP/1.1
Host api.discogs.com
Proxy-Connection keep-alive
Accept */*
User-Agent Yate/3.11 +http://2manyrobots.com
Accept-Language ru
Accept-Encoding gzip, deflate
Connection keep-alive
... And of course it results in 400 Bad Request.
HTTP/1.1 400 BAD REQUEST
Server nginx/1.8.1
Date Wed, 16 Mar 2016 21:23:26 GMT
Content-Type text/plain
Content-Length 408
Connection keep-alive
X-Discogs-Media-Type discogs.v2
Access-Control-Allow-Origin *
FYI: mapping requests from HTTP to HTTPS via Charles changes the error to 401 Unauthorized (which is quite expected due to invalid signature).
Do you guys have any plans on fixing this issue?
Regards,
Alexander
|