tafax
commented
9 years ago Unfortunately, avoiding the default handling of the HTTP authentication seems not possible. So, when the browser parses the response with a status code 401 and a standard header, it always displays the standard form. There are two possibilities:
- Return a generic 400 error instead of 401.
- Return a generic (custom) header for the authentication.
Either options produce a non-standard behavior in both client and server side. I personally suggest to handle the authentication with OAuth, but if you can work in the server code and change the header you can use this small library to mask the HTTP authentication and improve the user experience with a "standard" login form. Anyway, if you know a better solution to avoid the displayng of the standard browser form, your help is very appreciated.
wu-lee
The README says:
This seems to imply that is the WWW-Authenticate header is present, the usual browser prompt will appear? However, if the server does not use WWW-Authenticate then arguably it isn't using standard HTTP-Digest authentication, but a non-standard variation of it.
Also, I'm not clear if this is required just for the sign-in URL, or all URLs (I would assume the latter, but that makes the whole API exposed by the server non-standard, not just one URL, which would allow the rest of the API to stick to the standards and thereby interoperate with other clients besides the AngularJS UI using this module).
Can you clarify: can this module be used with standard http-digest with WWW-Authenticate, or does some or all occurrences of the WWW-Authenticate header need to be prevented for it to work?
Thanks!