Am 31.10.2015 1:39 vorm. schrieb chris derham <ch...@derham.me.uk>: > > > 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
