On 10/28/2015 12:04 PM, André Warnier (tomcat) wrote:
The server supports two kinds of deployment: Standalone with an
embedded Jetty-server and as war-file for app-servers (most of them
are tomcat-server). I try to suppress the browser BASIC-login-dialog
for the REST-service-calls from AngularJS.
On Jetty I modify the 401-responses and replace the "WWW-Authenticate"
header by anything else than "BASIC" and that works, now I try to
find a solution for the deployment on tomcat servers.
[.. snipped ..]
1) if the server sends to the client an authentication header saying
HTTP Basic, then the client will popup a builtin HTTP Basic dialog
(which you do not want)
2) if the server sends to the client an authentication header saying
something else, then the client cannot handle it
1 + 2 = solution impossible
You mentioned before that with another server than Tomcat, you solved
this apparently impossible problem. Can you tell us how ?
Or else, can you tell us which authentication methods, /apart/ from HTTP
Basic, the client does support ?
I've seen the behavior that Torsten is attempting to achieve, but I
think the issue is a fundamental lack of understanding of the protocol
on his part. This is assuming I'm understanding what he's trying to get at.
He's saying that in a regular http basic 401 exchange, if you remove the
WWW-Authenticate header, it will actually prevent the some clients from
popping up a dialog. I've seen this before with some clients. I'm not
sure if all clients react this way. The hold HTTPClient (not the apache
commons one, but one hosted on a .cz domain? something like that. This
is along long time ago) had that behavior. I admit I've never seen that
behavior in a browser but never tried.
RFC 2617 states this:
The 401 (Unauthorized) response message is used by an origin server
to challenge the authorization of a user agent. This response MUST
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource.
I don't think it's unreasonable to assume state that tomcat (or just
about any standards compliant web server) when serving up HTTP Basic
authentication will provide a complete and valid response and nothing else.
I may be misunderstanding, but my interpretation is Torsten simply wants
the client handling the RESTful service to never have to be accidentally
prompted to authenticate. If it screwed up and didn't send an
Authorization header to begin with, then skip the www-authenticate
header and hide the failure from the user.
If this is the case, I know of no way to do this short of
a) an intermediate proxy doing the work
b) creating your own authentication handler in tomcat to detect your
user-agent and spit back custom 401 responses depending on the agent.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org