Re: AW: AW: Suppress or replace WWW-Authorization header
Am 31.10.2015 1:39 vorm. schrieb chris derham : > > > I want to say thank you all for your help and many different ways to solve > > my problem. I think the most -maybe all- will work in an ideal world > > without > > hard requirements through legacy client-applications. I don't want to hold > > on BASIC as auth-method because I like it so much, I prefer to kick that > > legacy application. ^^ > > Torsten, > > If you have fixed it, then perhaps I should stop trying to help you. > However I reviewed the previous posts, and think that there was a key > aspect that I didn't mention before. So for the benefit of the email > archive, I'll give it another go. > > Setup you landing/index page to be public, i.e. no authentication. The > AngularJS html/js/css/pngs all load freely. I assume that this isn't > too much of an issue, e.g.you want to prevent people accessing the app > unless they have logged in. Then make all RestAPI calls to a > sub-directory called say /api/. Add security restrictions to this > sub-directory. As the app starts up, any call to any rest api will > return a 401. As all calls are ajax, no browser login popup. The > global AngularJS ajax error handler I posted previously captures the > response. So when the server detects no (or expired) session, it > returns a 401, & AngularJS global error handler detects this & > redirects to login page. Login page captures credentials, posts to > login api (which obviously needs to be not protected as well), and > then upon success, sends a cookie (or auth token of some sort). Then > AngularJS can send this cookie (or auth token) in each subsequent > RestApi call, e voila. > > I just tested the app I am developing that does this, in Edge, IE, > Chrome & Firefox. All working perfectly. No "ugly" login dialog in > sight. The key point I neglected to mention in my earlier post is that > you need to make sure that the host page is not behind the security. > If you are unwilling to do this, then they will have login before > accessing the app. In which case you can't really do anything about > it. > > HTH > > Chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > the angularjs page is already free available, my problem is that i'm not allowed to remove auth-method BASIC or the security-constraint for the rest-api-url. but you are right, your solution is much better and cleaner than my dirty hack if you can switch to form-based login or handle login in application logic... but if you have to keep the BASIC protection: what if the session is invalidated from server side (session timeout, logout in another browser tab)? the client thinks he is logged in, sends a request do the protected api and the server response with WWW-Authenticate: BASIC ... the browser shows that dialog without a chance to suppress or to handle it in angular. but u are right, without legacy software, your solution is to prefer. chris, i thank you very much for your help! :-) and it's nice to see that i'm not the only angularjs developer here... if you are interested, we can stay in contact at linkedin, skype or so and exchange best practices... because they are not easy to find for real big angular applications. - Torsten Rieger - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Suppress or replace WWW-Authorization header
> I want to say thank you all for your help and many different ways to solve > my problem. I think the most -maybe all- will work in an ideal world without > hard requirements through legacy client-applications. I don't want to hold > on BASIC as auth-method because I like it so much, I prefer to kick that > legacy application. ^^ Torsten, If you have fixed it, then perhaps I should stop trying to help you. However I reviewed the previous posts, and think that there was a key aspect that I didn't mention before. So for the benefit of the email archive, I'll give it another go. Setup you landing/index page to be public, i.e. no authentication. The AngularJS html/js/css/pngs all load freely. I assume that this isn't too much of an issue, e.g.you want to prevent people accessing the app unless they have logged in. Then make all RestAPI calls to a sub-directory called say /api/. Add security restrictions to this sub-directory. As the app starts up, any call to any rest api will return a 401. As all calls are ajax, no browser login popup. The global AngularJS ajax error handler I posted previously captures the response. So when the server detects no (or expired) session, it returns a 401, & AngularJS global error handler detects this & redirects to login page. Login page captures credentials, posts to login api (which obviously needs to be not protected as well), and then upon success, sends a cookie (or auth token of some sort). Then AngularJS can send this cookie (or auth token) in each subsequent RestApi call, e voila. I just tested the app I am developing that does this, in Edge, IE, Chrome & Firefox. All working perfectly. No "ugly" login dialog in sight. The key point I neglected to mention in my earlier post is that you need to make sure that the host page is not behind the security. If you are unwilling to do this, then they will have login before accessing the app. In which case you can't really do anything about it. HTH Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Suppress or replace WWW-Authorization header
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 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 : FORM webapp global realm /login.jsp /error_login.jsp 2015-10-28 16:28 GMT+01:00 Torsten Rieger : -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 28. Oktober 2015 15:39 An: Tomcat Users List 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 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) or (b) 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 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 :-/ Torsten, let me try again another way : 1) >> 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. :-/ No, you probably are not. But *this has nothing to do with Tomcat per se*. Any other webserver, in the same circumstances, would send a 401 back, with a request for HTTP Basic authentication. If, at the server level, you configure that for this application, you want HTTP Basic authentication, then that is what you will get. It is not a choice of the server, it is something *imposed* by the HTTP protocol. If you want something else to happen, but still have the client be authenticated for that application, then you have to change the authentication method required, at the server level. No way around it. 2) If the browser receives a 401 response header which indicates that the requested authentication method should be HTTP Basic, then it will popup its bultin HTTP Basic authentication popup dialog. There is no easy way around this either, because this behaviour is built-in into the code of all major browsers. (Also because the HTTP protocol says that this is what the browser should do). If you want this to be different, then you have to find a way to modify the browser-side logic, so that it does not do that. Doing this is possible, but not easy (see some of the other responses), and if not done correctly, it will be buggy and/or introduce security issues. 3) all the responses which I have seen so far on this thread, are technically correct consid
Re: AW: AW: Suppress or replace WWW-Authorization header
Torsten, On 10/28/15 11:28 AM, Torsten Rieger wrote: > -Ursprüngliche Nachricht- > Von: Christopher Schultz [mailto:ch...@christopherschultz.net] > Gesendet: Mittwoch, 28. Oktober 2015 15:39 > An: Tomcat Users List > 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 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) or (b) 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. :-/ How does your application know when the WWW-Authenticate header is okay to remove from the response? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: AW: Suppress or replace WWW-Authorization header
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 > 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 : > > > FORM > webapp global realm > >/login.jsp >/error_login.jsp > > > > > > > 2015-10-28 16:28 GMT+01:00 Torsten Rieger : > >> -Ursprüngliche Nachricht- >> Von: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Gesendet: Mittwoch, 28. Oktober 2015 15:39 >> An: Tomcat Users List >> 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 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) or (b) 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, 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 ? 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
Re: AW: AW: Suppress or replace WWW-Authorization header
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
Re: AW: AW: Suppress or replace WWW-Authorization header
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 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 : FORM webapp global realm /login.jsp /error_login.jsp 2015-10-28 16:28 GMT+01:00 Torsten Rieger : -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Mittwoch, 28. Oktober 2015 15:39 An: Tomcat Users List 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 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) or (b) 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, 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 ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
