Re: AW: Suppress or replace WWW-Authorization header
On 29.10.2015 10:12, chris derham wrote:
Torsten,
Add an interceptor to AngularJS to detect the 401 and do whatever you
want, e.g. redirect to a login page. Then when you have the
credentials, submit to login rest api, get a token, and then make all
other calls passing this token.
There are loads of examples on how to do this on the internet. This
isn't tomcat specific.
function globalInterceptorResponse($injector, $q) {
return {
'response': function (response) {
return response;
},
'responseError': function (rejection) {
switch (rejection.status) {
...
case 401:
console.warn("Hit 401 - redirecting to login");
window.location = '/login';
break;
...
default:
console.warn(rejection);
}
return $q.reject(rejection);
}
};
}
globalInterceptorResponse.$inject = ['$injector', '$q'];
then in request config,
$httpProvider.interceptors.push(globalInterceptorResponse);
This won't work because the application doesn't get a chance to do
anything until Tomcat completes its authentication/authorization work.
If the application were handling the authentication/authorization, then
the original Filter would have worked.
-chris
Chris,
I think that you thought the above was server-side java code. The
above was javascript code that runs in the browser. It does work - I
copied it from a project I am working on now.
Hi.
I will not dispute the fact that this solution works for you, and that it could also work
for Torsten. And I must say that it looks elegant, from a javascript point of view.
I will just submit a personal opinion, based on long experience, that says that any
solution (for this kind of interacting-with-servers issue) which is browser-based, is
always more fragile and inherently more unstable, than a solution based on normal HTTP
interactions and implemented at the server side. (*)
There are always little differences among browsers and browser versions, as to how they
handle javascript code. And there are many things that a user can do with his browser,
that can interfere with such things.
And problems on that side will always be very time-consuming to identify and
debug.
A server-side, protocol-compliant solution on the other hand, will work with any
HTTP-compliant browser (which does not necessarily include all versions of Internet
Explorer), and be a lot easier to maintain.
End of opinion.
(*) with an exception for all the marvelous things which you can do with tools like
jQuery, when used judiciously at the level of the browser-side presentation and user
interaction.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Suppress or replace WWW-Authorization header
Chris,
On 10/29/15 5:12 AM, chris derham wrote:
>>> Torsten,
>>>
>>> Add an interceptor to AngularJS to detect the 401 and do whatever you
>>> want, e.g. redirect to a login page. Then when you have the
>>> credentials, submit to login rest api, get a token, and then make all
>>> other calls passing this token.
>>>
>>> There are loads of examples on how to do this on the internet. This
>>> isn't tomcat specific.
>>>
>>> function globalInterceptorResponse($injector, $q) {
>>> return {
>>> 'response': function (response) {
>>> return response;
>>> },
>>> 'responseError': function (rejection) {
>>> switch (rejection.status) {
>>> ...
>>> case 401:
>>> console.warn("Hit 401 - redirecting to login");
>>> window.location = '/login';
>>> break;
>>> ...
>>> default:
>>> console.warn(rejection);
>>> }
>>> return $q.reject(rejection);
>>> }
>>> };
>>> }
>>> globalInterceptorResponse.$inject = ['$injector', '$q'];
>>>
>>> then in request config,
>>>
>>> $httpProvider.interceptors.push(globalInterceptorResponse);
>>
>> This won't work because the application doesn't get a chance to do
>> anything until Tomcat completes its authentication/authorization work.
>> If the application were handling the authentication/authorization, then
>> the original Filter would have worked.
>>
>> -chris
>
> Chris,
>
> I think that you thought the above was server-side java code. The
> above was javascript code that runs in the browser. It does work - I
> copied it from a project I am working on now.
Yes, I was missing the fact that parts (or all?) of AngularJS run on the
client. Thanks for clarifying that bit.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Suppress or replace WWW-Authorization header
>> Torsten,
>>
>> Add an interceptor to AngularJS to detect the 401 and do whatever you
>> want, e.g. redirect to a login page. Then when you have the
>> credentials, submit to login rest api, get a token, and then make all
>> other calls passing this token.
>>
>> There are loads of examples on how to do this on the internet. This
>> isn't tomcat specific.
>>
>> function globalInterceptorResponse($injector, $q) {
>> return {
>> 'response': function (response) {
>> return response;
>> },
>> 'responseError': function (rejection) {
>> switch (rejection.status) {
>> ...
>> case 401:
>> console.warn("Hit 401 - redirecting to login");
>> window.location = '/login';
>> break;
>> ...
>> default:
>> console.warn(rejection);
>> }
>> return $q.reject(rejection);
>> }
>> };
>> }
>> globalInterceptorResponse.$inject = ['$injector', '$q'];
>>
>> then in request config,
>>
>> $httpProvider.interceptors.push(globalInterceptorResponse);
>
> This won't work because the application doesn't get a chance to do
> anything until Tomcat completes its authentication/authorization work.
> If the application were handling the authentication/authorization, then
> the original Filter would have worked.
>
> -chris
Chris,
I think that you thought the above was server-side java code. The
above was javascript code that runs in the browser. It does work - I
copied it from a project I am working on now.
Chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Suppress or replace WWW-Authorization header
Hi. on this list, as per http://tomcat.apache.org/lists.html#tomcat-users #6 , it is preferred if you respond below the question being asked (or the previous response) rather than on top. (The main reason being that it is easier that way to follow the normal gist of the conversation, rather than having to scroll back and forth to figure out what you are responding to.) On 28.10.2015 13:19, 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. Can you copy and paste here the WEB-INF/web.xml of that server application ? (remove any sensitive data). There is probably a way to do this via configuration in Tomcat (I haven't looked it up), but you could also have a look at a standard workhorse for this kind of thing : the UrlRewriteFilter (http://tuckey.org/urlrewrite/). It might provide a way to do this. (I have not really checked it either, but this looks promising : http://cdn.rawgit.com/paultuckey/urlrewritefilter/master/src/doc/manual/4.0/index.html#outbound-rule See the response-header part. ) 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. One thing which is still not clear : do you really want to remove/replace that header, or do you just want that this application would not request authentication at all ? (Then there would be no need to play with the 401 header, because there would never be one). -Ursprüngliche Nachricht- Von: André Warnier (tomcat) [mailto:a...@ice-sa.com] Gesendet: Mittwoch, 28. Oktober 2015 10:26 An: users@tomcat.apache.org Betreff: Re: Suppress or replace WWW-Authorization header Hi. On 28.10.2015 09:36, Torsten Rieger wrote: Hi, I try to suppress the browser login-dialog on basic authentication (basic is a legacy requirement), how can I do that? Filters are called after login on the container, right? I am not sure that I understand exactly what you mean here, and I certainly do not understand the purpose of what you are trying to do, but here is some informaytion that may help : The general authentication logic in HTTP works (roughly) as follows : 1) the browser sends a request to the server, for some resource (HTML page or else) 2) the server checks if access to the requested resource resource requires authentication/authorization. If not, go to 8 3) (if yes) : the server checks if the requesst already contains an authentication of the required type, and if yes, if it is valid. If yes, go to 8 4) (if not) : the server returns a status code 401 (authorization required) to the browser, along with *the kind of authentication* required (this is defined in the server configuration for that resource) 5) the browser obtains the required authentication credentials (in a way which depends on the type of AAA required) 6) the browser repeats the request to the server, this time providing the required credentials, in the form corresponding to what the server indicated in (4). 7) back to (2) above. 8) the server returns the requested resource. Now your case is apparently so that at step (4) above, the 401 response that the server sends back to the browser, specifies "HTTP Basic" as the requested form of authentication/credentials. In such a case, the browser (all browsers), at step (5), *will* popup a Basic authentication dialog, and there is nothing that you can do about it. It is a behaviour that is built-in in all browsers, and it is what is expected of them. (In other words also, this dialog is not something that is sent by the server, so you cannot "filter it out"). The only way to avoid such a dialog in the browser, is at the level of the server, ensuring that the 401 responses do not specify "Basic" as the requested authentication method. If the above does not answer yopur question, please provide more details about what you are trying to do, and the purpose of it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail:
Re: AW: Suppress or replace WWW-Authorization header
On 28.10.2015 15:39, Christopher Schultz wrote: 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. Yes, but if the SOAP-client is an applet in the browser, chances are that in order to collect the user credentials that it needs, it uses the internal browser mechanism, which pops up the dialog to obtain these user credentials. So not so weird necessarily. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
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 <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 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 > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: AW: Suppress or replace WWW-Authorization header
On 28.10.2015 16:55, chris derham wrote:
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
Torsten,
Add an interceptor to AngularJS to detect the 401 and do whatever you
want, e.g. redirect to a login page. Then when you have the
credentials, submit to login rest api, get a token, and then make all
other calls passing this token.
There are loads of examples on how to do this on the internet. This
isn't tomcat specific.
function globalInterceptorResponse($injector, $q) {
return {
'response': function (response) {
return response;
},
'responseError': function (rejection) {
switch (rejection.status) {
...
case 401:
console.warn("Hit 401 - redirecting to login");
window.location = '/login';
break;
...
default:
console.warn(rejection);
}
return $q.reject(rejection);
}
};
}
globalInterceptorResponse.$inject = ['$injector', '$q'];
then in request config,
$httpProvider.interceptors.push(globalInterceptorResponse);
Chris
What is maybe not totally clear for the OP above, is that the above is done at the level
of the client (browser). Not at the tomcat level.
(Which is maybe also why Torsten did not find anything when he previously searched the web
: he was searching with the wrong keywords).
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Suppress or replace WWW-Authorization header
> 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
Torsten,
Add an interceptor to AngularJS to detect the 401 and do whatever you
want, e.g. redirect to a login page. Then when you have the
credentials, submit to login rest api, get a token, and then make all
other calls passing this token.
There are loads of examples on how to do this on the internet. This
isn't tomcat specific.
function globalInterceptorResponse($injector, $q) {
return {
'response': function (response) {
return response;
},
'responseError': function (rejection) {
switch (rejection.status) {
...
case 401:
console.warn("Hit 401 - redirecting to login");
window.location = '/login';
break;
...
default:
console.warn(rejection);
}
return $q.reject(rejection);
}
};
}
globalInterceptorResponse.$inject = ['$injector', '$q'];
then in request config,
$httpProvider.interceptors.push(globalInterceptorResponse);
Chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Suppress or replace WWW-Authorization header
Chris,
On 10/28/15 11:55 AM, chris derham wrote:
>> 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
>
> Torsten,
>
> Add an interceptor to AngularJS to detect the 401 and do whatever you
> want, e.g. redirect to a login page. Then when you have the
> credentials, submit to login rest api, get a token, and then make all
> other calls passing this token.
>
> There are loads of examples on how to do this on the internet. This
> isn't tomcat specific.
>
> function globalInterceptorResponse($injector, $q) {
> return {
> 'response': function (response) {
> return response;
> },
> 'responseError': function (rejection) {
> switch (rejection.status) {
> ...
> case 401:
> console.warn("Hit 401 - redirecting to login");
> window.location = '/login';
> break;
> ...
> default:
> console.warn(rejection);
> }
> return $q.reject(rejection);
> }
> };
> }
> globalInterceptorResponse.$inject = ['$injector', '$q'];
>
> then in request config,
>
> $httpProvider.interceptors.push(globalInterceptorResponse);
This won't work because the application doesn't get a chance to do
anything until Tomcat completes its authentication/authorization work.
If the application were handling the authentication/authorization, then
the original Filter would have worked.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
