tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: AW: Suppress or replace WWW-Authorization header
Date Thu, 29 Oct 2015 13:03:21 GMT
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.


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 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message