-----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. :-/
>
> -torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


The Problem is then, that login via "Authorization: BASIC xyz==" will not
work anymore... the legacy client is not able to handle FORM based login :-/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to