Cross Origin Request Blocked: User Agent on discovery fetch

[Leon0402]

What happened?

I'm getting CORS errors with discoveryRequest and GitLab. Some minimal reproducable code:

const issuer = new URL("https://gitlab.com/.well-known/openid-configuration");
const as = await oauth.discoveryRequest(issuer);

I'm not a web developer, but I'm quite sure it is related to the library overriding the user-agent in prepareHeaders. Some minimal reproducable code without using the library:

const issuer = new URL("https://gitlab.com/.well-known/openid-configuration");

const headers = new Headers();
headers.set("user-agent", "oauth4webapi/v1.0.3"); // Works without this line
headers.set("accept", "application/json");

fetch(issuer.href, { headers, method: "GET", redirect: "manual" })
  .then((response) => response.json())
  .then((data) => console.log(data));

Should the user-agent really be the library? Usually it is the browser, isn't it?

Version

v1.0.3

Runtime

Browser

Runtime Details

Linux, Firefox & Chrome

Code to reproduce

const issuer = new URL("https://gitlab.com/.well-known/openid-configuration");
const as = await oauth.discoveryRequest(issuer);

Required

• I have searched the issues tracker and discussions for similar topics and couldn't find anything related.
• I agree to follow this project's Code of Conduct

[Leon0402]

I actually checked again and discoveryRequest is neither working in Firefox nor Chrome. But my second code with fetch content actually works in Chrome. So while user-agent is (one of) the reasons it is not working in Firefox, there must be some other reason for chrome.

[panva]

I actually checked again and discoveryRequest is neither working in Firefox nor Chrome.

You need to use it right first, the Issuer Identifier URL instance you pass in must be new URL('https://gitlab.com'), not including the well known components.

See CORS made discovery from Chrome.

Please reach out to gitlab support with this issue of theirs first. There's something awry with their CORS configuration when non-default user-agent is provided. This discovery mechanism works against other providers. Happy to look into it again if it turns out to be a non-gitlab specific issue.

Also keep in mind, as a workaround, you can discover / obtain the metadata object any way that works for you with gitlab.

[panva]

You can also pass custom headers to all network utilizing functions. So you may just pass a Headers instance with user-agent being the navigator.userAgent which would be otherwise used by default if not defined by the library.

Edit: nevermind, even when passing a user-agent that's the same as navigator.userAgent the CORS preflight request results in not allowing CORS. This is a gitlab specific issue in that their OPTIONS preflight response is not right. They possibly intentionally don't support public browser clients? Only gitlab can tell.

[panva]

Trying with other providers, they seem to run into a similar issue. So what i'll do instead is not set the user-agent header when in browser environment, this means no CORS preflight has to be done, or at least it won't trip CORS off.

For the record this is an issue with the identity provider's invalid CORS configuration, not the library. It is absolutely okay to set a custom user-agent.

[panva]

https://github.com/panva/oauth4webapi/releases/tag/v1.0.4

[Leon0402]

You need to use it right first, the Issuer Identifier URL instance you pass in must be new URL('https://gitlab.com'), not including the well known components.

Oh yes, you're right!

I think the reason that it's not working in firefox, but in chromium, might be that settings the user agent is not possible in chromium? At least I read this in various sources and found an open bug for it:

https://bugs.chromium.org/p/chromium/issues/detail?id=571722

Additionally when looking at my network tab, the user agent is not set to oauth4webapi/v1.0.3, but to the default value.

The SO answer https://stackoverflow.com/a/42815264/10764260 provided that link and also said that a custom user-agent used to be not allowed. So that might be a possible explanation why GitLab (and others) forbid it?

Again, I have very little experience with web stuff. So I'm just guessing here.

Edit: Why do you set user-agent in the first place? Does it have any use?

[Leon0402]

https://github.com/panva/oauth4webapi/releases/tag/v1.0.4

I can confirm that your commit fixed the issue in firefox and chromium. Thanks for your quick help!

[panva]

Why do you setting user-agent in the first place?

Because we technically should be able to do so and the default fetch user-agent strings on non-browser runtimes (e.g. workers, deno, ...) are even more useless than the browser ones.