/token from javascript app opens browser basic auth popup about restify-oauth2

[domenic]

That's fascinating. I wonder if it's Chrome-specific? Did you try other browsers?

I assume these things you are using to make the request are using XMLHttpRequest?

In the upcoming Fetch Standard, this is called out explicitly; see "Let username and password be the result of prompting the end user for a username and password".

From the spec I can't figure out how to set the "use URL credentials" flag from the API. @annevk? I think it's an important use case to support, avoiding the popup dialog. Is this missing from fetch, or is my reading incomplete?

[domenic]

OK, at least in the XHR spec (not in the Fetch spec, unsure why) the use URL credentials flag gets set if the URL contains username or password components. Since you obviously don't want to do that, it seems that per-spec there's no way to just disable the prompt. (Since if the use URL credentials flag is unset, the prompt will happen.)

So I am going to call this a missing feature of the spec: it should give you a way to view the raw response and not prompt the user for a username/password on failure. Very interesting.

@annevk, want me to file a bug on Fetch?

[annevk]

For fetch() request's authentication flag would not be set so you would get back the 401. Which is what we want, no?

[mikemilano]

I confirmed it is not an issue in Firefox.

For Chrome, it is the WWW-Authenticate header being set to Basic in the response.

I found another framework getting around this by setting that value to x-Basic.

I modified lib/cc/grantToken.js to this and it did indeed suppress the popup:

if (!token) {
            res.header("WWW-Authenticate", "x-Basic realm=\"Client ID and secret did not authenticate.\"");
            return next(makeOAuthError("Unauthorized", "invalid_client", "Client ID and secret did not authenticate."));
        }

Perhaps this could be a config if breaking standards by default is a concern.

[domenic]

@annevk by my reading Fetch never sets the "use URL credentials flag". Since the clause is:

If request's use URL credentials flag is unset, or the authentication fetch flag is set, run these substeps:

The first part of the "or" clause is true, so those steps will always be run in Fetch.

@mikemilano I'm not sure how comfortable I am telling users to authenticate with X-Basic but then only accepting Basic authentication headers. Maybe we'd need a config where it tells you to authenticate with X-Basic and then only accepts X-Basic authentication headers.

The fact that this is non-interoperable between Chrome and Firefox is very interesting. We should test the other browsers (Safari, IE) and file bugs to get them all on the same page.

[annevk]

@domenic it terminates at step 1 of handling the 401 due the authentication flag being unset.

[domenic]

Ah of course, sorry I missed that. Cool, Fetch is all good :D.

[mikemilano]

@domenic My suggestion didn't require the request to change at all. The user authenticates with Authorization: Basic .... The difference is in the response header. WWW-Authenticate is set in grantToken.js. Changing Basic to x-Basic is the workaround.

My suggestion, or request, is to create a way for the default WWW-Authenticate response header to be overridden. It could be done with either a config variable, or perhaps overridden via a custom plugin that manipulates res. grantToken.js would just need to set that word based on a config, or default it to Basic.

Alternatively, if there's no concern since it's just the response header we're talking about, x-Basic could just be hardcoded as the header is set now.

[domenic]

Yes, the issue is that the WWW-Authenticate header is what tells you how to do the request. It tells you to do Basic authorization, so that's what you should do. If it tells you to do X-Basic, then a well-behaved client will send X-Basic authorization (whatever that is). So the server should probably support X-Basic, and not Basic, in that case.

[mikemilano]

Ah I see. My rest client may not be following the spec since it does not consider that header response.

Perhaps a corner case, but that header being inconsistent has no impact with how I'm using this module vs the chrome issue, which makes this module as it sits, unusable for my application (and any JS client in chrome).

The override would be nice, but I can just roll with a modified fork.

I appreciate the attention in helping me understand the issue and thanks for this module.