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
