graphhopper/graphhopper-maps

What happens if API key is invalid?

Closed this issue · 8 comments

When I use an invalid API key, the fetch(...) method does not respond with the status code 401 and the message:

{"message": "Wrong credentials. Register and get a valid API key at https://www.graphhopper.com/developers/"}

, but tells me something about

Access to fetch at 'https://graphhopper.com/api/1/info?key=bloed' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

and

Failed to load resource: net::ERR_FAILED

Does anyone have any idea how to get what I would expect here? I.e.

response.status: 401 
response.json(): {"message":"Wrong credentials. Register and get a valid API key at https://www.graphhopper.com/developers/"}

Yes, this is a known issue of our API that in case of an invalid API key you get this cryptic error message (we have to improve this). But this has nothing to do with GH Maps.

No, it has nothing to do with our API. Our API responds with status 401 and a message as I would expect. It is related to the react fetch() method.

I just want GH Maps to receive exactly that & accordingly give an error indicating that my API key is wrong & not drooling something about Cors-Access.

IMO this is due to missing CORS headers when the API key is missing (in the prefetch request). This is unrelated to GH Maps and something we have to fix on the server-side.

If I use Postman and send the exact same request with an invalid API key, I get:

{
    "message": "Wrong credentials. Register and get a valid API key at https://www.graphhopper.com/developers/"
}

and status 401.

What can Postman, what our react app cannot?

When I make a route request to the API and do it with React's fetch() method, the browser app sends a preflight request to ask the server if it accepts the POST method or certain headers, for example. For the preflight request, it uses the HTTP method OPTIONS. Now, if I send a request with an invalid API key, the app sends a preflight request beforehand (with this API key) to ask if it is allowed to send a POST request at all. Our API receives this preflight request and does not answer the question whether it is allowed to send POST requests. Instead, it checks the API key in the preflight request and determines that it is invalid and responds with 401 (not authorized). However, this is the wrong response. Because the question is not whether the owner of this particular API key is allowed to send requests, but whether the API generally allows POST requests with headers x u. y. With this 401 answer, the browser app thinks, whoops, I'm not allowed to make POST requests, and doesn't even send the actual POST (with the invalid api key) request.

So the solution here is to teach the API servers to answer the questions, i.e. when the question comes if POST request are allowed, I have to answer here with yes or 200. The preflight requests can be easily recognized by the HTTP method OPTIONS.