WWW-Authenticate:x-Basic instead Basic

[fabioginzel]

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

[weierophinney]

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

• http://loudvchar.blogspot.ca/2010/11/avoiding-browser-popup-for-401.html

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)?

[ezimuel]

@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/

[fabioginzel]

@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

[fabioginzel]

Help-me :)

[weierophinney]

@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.

[nuxwin]

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 Added configurable http authentication resolver #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.

[weierophinney]

This repository has been closed and moved to laminas-api-tools/api-tools-mvc-auth; a new issue has been opened at laminas-api-tools/api-tools-mvc-auth#23.