On 28.10.2015 17:42, Torsten Rieger wrote: > -----Ursprüngliche Nachricht----- > Von: Aurélien Terrestris [mailto:aterrest...@gmail.com] > Gesendet: Mittwoch, 28. Oktober 2015 16:45 > An: Tomcat Users List <users@tomcat.apache.org> > Betreff: Re: AW: Suppress or replace WWW-Authorization header > > You can choose between a pop-up or an HTML FORM > > This one looks like this in web.xml : > > <login-config> > <auth-method>FORM</auth-method> > <realm-name>webapp global realm</realm-name> > <form-login-config> > <form-login-page>/login.jsp</form-login-page> > <form-error-page>/error_login.jsp</form-error-page> > </form-login-config> > </login-config> > > > > > 2015-10-28 16:28 GMT+01:00 Torsten Rieger <torsten.rie...@promatis.de>: > >> -----Ursprüngliche Nachricht----- >> Von: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Gesendet: Mittwoch, 28. Oktober 2015 15:39 >> An: Tomcat Users List <users@tomcat.apache.org> >> Betreff: Re: AW: Suppress or replace WWW-Authorization header >> >> Torsten, >> >> On 10/28/15 8:19 AM, Torsten Rieger wrote: >>> I have a legacy java-SOAP-client that only supports BASIC >>> authentication (send the Authorization: Basic... header) and a >>> AngularJS application that consumes a REST-service (also sending the >>> Authorization: Basic header). >>> >>> 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. >>> >>> Rewrite (unset header in responses) with an apache proxy in front of >>> the tomcat is unfortunately not a solution I can implement. >>> >>> So I'm looking for a solution to remove or modify the headers in 401 >>> responses on application server level. >> >> So you just want to disable HTTP BASIC authentication? Why not just >> remove the <auth-method> from web.xml and disable authentication entirely? >> >> Are you saying that when you connect using a REST client, the client >> shows a login dialog in a web browser? That sounds ... weird. The >> REST client should see the WWW-Authenticate header and either (a) >> fail or >> (b) re-try with credentials you have provided to it. >> >> -chris >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> No, container BASIC authentication should be enabled, the container >> should handle the authentication, but the browser should not show his >> ugly default login dialog when I request resources from the >> REST-service with wrong credentials. >> When the REST-client (web-application in the browser) receives a >> failed login with a WWW-Authenticate header, the default dialog of >> the browser will be shown... that’s what I want to suppress. >> >> When I remove the (a) <login-config> or (b) <auth-method> sending >> requests with credentials will not work anymore (a: 403 forbidden; b: >> deployment fails). But that's not a solution because the rest-service >> should be still protected and I need to authenticate via "Authentication: >> Basic ....." >> header send credentials, but I don't want to show the ugly >> browser-dialog to the users. >> >> Using a AngularJS Client with REST-services based on tomcat should be >> a common use-case, it could not be that I'm the first one who wants a >> custom login-screen. :-/ >>
<quote> Torsten, the people answering on this list are generally competent and helpful. But they are not magicians. You seem (so far) to be asking something impossible. 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 ? </quote> Perhaps the OP wants this page [1]. It describes a technique which appears to do what he wants. George [1] https://www.freelock.com/2008/06/technical-note-http-auth-with-ajax --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
