Exposing custom headers for CORS
levionan.8506:
Hi,
I was trying out GW2 API using AngularJS (a Javascript framework) and I’m encountering an issue with respect to accessing the custom headers (e.g. X-Page-Size, X-Page-Total, etc) in the HTTP response.
Basically, the API server does not explicitly include the Access-Control-Expose-Headers in its response. The link below explains it better.
Refer: http://stackoverflow.com/questions/18124483/angularjs-ignoring-some-headers
Pat Cavit.9234:
Oof, good point. We’ll get it onto the backlog.
Pat Cavit.9234:
Hah, Lawton beat me to it. This is on dev now, we’ll bang on it for a bit & make sure it’s good.
levionan.8506:
That’s sweet. Thanks!
RedGlow.2715:
Hello!
I’m also working with the APIs and Angular.
Lately I’ve tried using the Authorization header instead of the query parameter in order to send an authorized request to some API endpoints – tokeninfo in this specific instance.
It seems to me that the situation is not really working yet: when the browser launches an OPTIONS request (apparently the presence of the Authorization header prompts the library/browser to preflight the request, and I don’t know enough of CORS to say if this is correct or not), the tokeninfo endpoint replies with a 404 (?).
May it help if I open a ticket on GitHub?
smiley.1438:
Simply put: preflight requests are not supported. Thats why the access_token parameter exists in first place.
Lawton Campbell.8517:
Lately I’ve tried using the Authorization header instead of the query parameter in order to send an authorized request to some API endpoints – tokeninfo in this specific instance.
Due to the way our backend works, we don’t support OPTIONS requests at all.
As a workaround, you should pass the API key via the ?access_token query parameter, e.g.
GET /v2/tokeninfo?access_token=$APIKEY
(Making better documentation is on my todo list ;_;)
smiley.1438:
(apparently the presence of the Authorization header prompts the library/browser to preflight the request, and I don’t know enough of CORS to say if this is correct or not)
Just to add: you are right here. If there’s a custom header set, a preflight request is being sent in order to determine if the main request is safe to send.
See https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests
RedGlow.2715:
Lately I’ve tried using the Authorization header instead of the query parameter in order to send an authorized request to some API endpoints – tokeninfo in this specific instance.
Due to the way our backend works, we don’t support OPTIONS requests at all.
As a workaround, you should pass the API key via the ?access_token query parameter, e.g.
GET /v2/tokeninfo?access_token=$APIKEY
(Making better documentation is on my todo list ;_;)
Oh, very well! I just thought the Authorization header seemed like a cleaner way to proceed, but I’ll just keep on using the access_token query parameter then :-)
In the meanwhile, I’ve added a paragraph in the API key page explaining the two possible alternatives and the problem here stated: http://wiki.guildwars2.com/wiki/API:API_key. (I hope the wiki masters won’t punish me because I’ve put the information in the wrong place, or with the wrong formatting, or anything else of the like ;-D)