authorization header and preflight requests
lynnae.4095:
using javascript XMLHttpRequest and setting the Authorization header via xhr.setRequestHeader(‘Authorization’,’Bearer ’ + token);
causes a preflight request to be sent because Authorization is considered to be a custom header.
Unfortunately the preflight request doesn’t look to be handled and Chrome reports:
XMLHttpRequest cannot load https://api.guildwars2.com/v2/account. No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Is this to be expected, and XMLHttpRequest can’t be used to access the protected resources, or do I have the wrong end of the stick for setting the bearer token? Or have the CORS headers gone walkabout?
StevenL.3761:
I can confirm that /v2/account does not respond with the ‘Access-Control-Allow-Origin’ header. Wait… it does. Maybe it only works for GET requests.
smiley.1438:
Don’t even try to use custom headers when using CORS requests – just append access_token=<API_KEY> to the request URL. Also, preflight requests are not supported.
Eearslya.6309:
I believe I’ve seen this issue posted before. The solution I saw then was to pass the API key as ?access_token=APIKEY instead of in the header. Not a perfect solution, but it’s probably your best bet.
lynnae.4095:
ta folks.
Since sending the preflight request is not something you can control when you set the Authorization header in javascript, I’ll try appending it to the query string as indicated.
ta for the tip, think this was the post that shows the query string key https://forum-en.guildwars2.com/forum/community/api/Cross-Origin-v2-transactions
and the original dev post response that preflight requests are not supported and listing the query string workaround:
https://forum-en.guildwars2.com/forum/community/api/Launching-v2-commerce-transactions/first#post5077482
smiley.1438:
However, you should avoid to use the API key via frontend scripting languages (as in JavaScript). Keep in mind that it is basically the OAuth2 access token which is intended to be used between the app`s backend and the gw2 API server.
lynnae.4095:
:) thanks. I’m aware.
Wizeon.3852:
However, you should avoid to use the API key via frontend scripting languages (as in JavaScript). Keep in mind that it is basically the OAuth2 access token which is intended to be used between the app`s backend and the gw2 API server.
Can you elaborate? The user has to send the api key via a frontend to the backend anyway, so it’s just as easily compromised at that point. And by not using a backend I basically guarantee to the user that I won’t do anything with their api keys since I don’t even see them. Not even talking about the time saved by not having to have a backend
Lawton Campbell.8517:
However, you should avoid to use the API key via frontend scripting languages (as in JavaScript). Keep in mind that it is basically the OAuth2 access token which is intended to be used between the app`s backend and the gw2 API server.
Eh, it’s not that big of a deal with the current API keys. With OAuth2, the access token was tied to the application so that e.g., an application could be billed or rate-limited. As such, OAuth2 applications need to ensure they never leak the access token to the user because that would allow the user to pretend they’re the application and make requests using that application’s credentials.
Since API keys aren’t tied to applications, there’s no need for an application to prevent the user from getting access to them.