Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WWW-Authenticate:x-Basic instead Basic #23

Open
weierophinney opened this issue Dec 31, 2019 · 6 comments
Open

WWW-Authenticate:x-Basic instead Basic #23

weierophinney opened this issue Dec 31, 2019 · 6 comments

Comments

@weierophinney
Copy link
Contributor

In Chrome when we return WWW-Authenticate:Basic and 401 status in xhr request it show a popup, to not show the popup must return x-base.

Sorry about my english


Originally posted by @fabioginzel at zfcampus/zf-mvc-auth#33

@weierophinney
Copy link
Contributor Author

Took a bit of research to figure out what you were getting at, but I think it's this:

In other words, instead of:

HTTP/1.1 200 OK
WWW-Authenticate: Basic realm=api

We'd send this:

HTTP/1.1 200 OK
WWW-Authenticate: xBasic realm=api

(and similarly for Digest).

@ezimuel What are your thoughts? This would break any services that you also decide to expose as HTML (as the authentication challenge dialog would never be presented), but would make it work properly when you are trying to access the API service via a browser.

That said... I've used Angular to access APIs that have HTTP Basic or Digest authentication, and not seen any request for a popup when making XHR requests. What library are you using when you see this, @fabioginzel ? and what browser/OS combination(s)?


Originally posted by @weierophinney at zfcampus/zf-mvc-auth#33 (comment)

@weierophinney
Copy link
Contributor Author

@weierophinney this occurs if you use a standard xhr in javascript without sending the authentication header. @fabioginzel did you try to set the Authorization header before the send? Here there is an example using jquery: http://blog.rassemblr.com/2011/05/jquery-ajax-and-rest-http-basic-authentication-done-deal/


Originally posted by @ezimuel at zfcampus/zf-mvc-auth#33 (comment)

@weierophinney
Copy link
Contributor Author

@weierophinney I'm using Chrome 35 in Ubuntu 14.04 and AngularJS
@ezimuel I tried, but it only works if the authentication is successful
In the blog they use status 403 instead of 401


Originally posted by @fabioginzel at zfcampus/zf-mvc-auth#33 (comment)

@weierophinney
Copy link
Contributor Author

Help-me :)


Originally posted by @fabioginzel at zfcampus/zf-mvc-auth#33 (comment)

@weierophinney
Copy link
Contributor Author

@fabioginzel We're still researching. We'll update here when we have any fixes. Changing the header at this point, however, could have backwards breaking implications for existing users, so we need to choose an approach carefully.


Originally posted by @weierophinney at zfcampus/zf-mvc-auth#33 (comment)

@weierophinney
Copy link
Contributor Author

An approach could be:

  • Permit the developer to set custom HTTP schemes (HTTP authentication is not restricted to Basic and Digest schemes). Those schemes are standard but you're allowed to use any schemes you want. For instance Google provides HTTP authentication for its API, using a custom scheme: GoogleLogin.
  • Permit to set custom resolvers for the HTTP adapter (it is already possible (See PR Update composer.json #40), but this should be maybe adapted.

About backward compatibility

It is currently possible to setup an authentication adapter per API. Thus, I don't see any problem there. The developer could setup an HTTP authentication adapter for a specific API/VERSION.

Anyway, generally, API calls are never made through a browser. They are done through a specific user agent such as cURL, API client library or even XHR call and all doesn't care about challenge box. They only have interest in HTTP status code (401 here) and the WWW-Authenticate header to known which schemes are available.


Originally posted by @nuxwin at zfcampus/zf-mvc-auth#33 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant