Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

CORS - OPTIONS request blocked on userinfo request

See original GitHub issue

Hi guys,

Thank you for this great application. It saved us a lot of time.

If the client app is not served by the same server as our Django OIDC provider, the OPTIONS request triggered by the browser on the /openid/userinfo URL fails for three reasons :

because the OPTIONS HTTP verb is blocked by the application
because the Authorization header is not sent to the server in the OPTIONS preflight
because the Authorization header is not whitelisted in the Access-Control-Allow-Headers

We coded a workaround on our side, but wanted to let you know of the problem. I would be surprised to be the first facing it.

If you have a recommanded solution, I would be happy to implement it.

All the best !

Issue Analytics

State:
Created 5 years ago
Comments:7 (3 by maintainers)

Top GitHub Comments

4reactions

q3aimlcommented, Jun 19, 2018

@juanifioren The spec also states:

The UserInfo Endpoint SHOULD support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to enable Java Script Clients to access the endpoint.

Supporting OPTIONS is part of supporting CORS: https://www.w3.org/TR/access-control/. The preflight OPTIONS request is a side effect of a GET or POST request issued by the client. The OPTIONS implementation only needs to return the relevant headers – it does not need to carry out the full userinfo request or return the standard response body.

3reactions

juanifiorencommented, Jul 2, 2018

to be released on next version