you're performing a jaas login, but - as you are bypassing the servlet engine - the servlet engine has no knowledge about this; that is why it is still redirecting you.
I don't see an easy fix for this; of course you can first do the cookie stuff and _then_ redirect to the normal servlet login page, but i guess that's not what you want as this would set the cookie stuff even if the user does not actually login.
However, i wonder why you do not use the session-creation event, which would provide a vendor-neutral solution also.
Thanks for your prompt response. And apologies for taking so long to follow up. Events overtook me on that day and then I went on holiday :) I really appreciate your help.
I had assumed that LoginContext would magically let the servlet engine about what had happened - ah well.
HttpSessionListener sounds interesting but I am tied to JSDK2.2 and it was only introduced in 2.3. Sigh.
I'm having a rethink about my design to see if I can do it all in a different way.
Thanks again for the advice.
A possible solution would be to the login all by yourself, e.g. using servlet filters (was that in before 2.3? ;-)). It's quite a bit of work, but then you are free to add anything in the login proces...
If you need more help on this topic, let me know.
I'm afraid filters are pre2.3 too :(
But I do have a solution :)
I do a login myself and then redirect to j_security_check explicitly (passing in the j_username, j_password and j_uri). So I actually end up logging in twice: once for me to check the credentials before writing my cookie, and once for the servlet container to login so that it is happy too.
I am sending them in the URL, but I suppose for security reasons I should really post them instead.
I guess that it is a bit like using filters, just a lot more clumsy. Oh, I wish the project used 2.3 :)
I don't think there are any disadvantages to logging in twice (other than a slight performance hit).
Thanks for the help.
Hi Bill ... It's been a while :), heard you've got an excellent wood burning stove these days.
I'm curious about how you got that to work - how does tomcat know where to forward to after j_security_check - I've never heard of j_uri being used other than as a non-standard extension in Resin.
I am also facing the same problem. I am looking for a way to have my start page contain a small login form which will enable the user to login from the site start page. Until now from what I've read... no answer - the only way that is there is to wait for the Tomcat to trigger the login form. It's not good enough sometimes, and I am surprised that this goes all the way down to the Servlet Spec.
The only solution I know of is having a start page with a link for login which will trigger the Tomcat container login process. Are we doomed to be stuck with it??
I am looking for a way to programmatically inform/login to the Tomcal. Is there a way? Secondly, could someone please elaborate on using a Servlet Filter to perform the login process.
If you want the welcome page to contain welcome info plus the login page why not do the following ...
Have the welcome page composed of 2 areas ... one that has the welcome info, and the other part that is added if the user is not logged in (you can programmatically check in your JSP for this). If the user is not logged in you just add the j_security_check FORM (you can put this j_security_check FORM in a separate JSP page that you do a jsp:include on).
That way when you start up your app, you get a welcome page with the login form included for people to enter into, and when they are logged in and they go to that page, they do not see the login FORM.
How are you? It has been a while... wood burning stove? How do you know about my wood burning stove? :) Well, it's a bit hot for it just now so it is serving as a flat suface for things to be piled up on.
// Grab the URI that was passed to login
String lUri = pRequest.getParameter(cURI_PARAMETER);
// Redirect to the servlet's login method. This means we login twice
// but we have to that or the server doesn't realise that we're logged
// in and we get redirected back to the login page.
StringBuffer location = new StringBuffer(pRequest.getContextPath());
location.append((lUsername != null) ? lUsername : "");
location.append((lPassword != null) ? lPassword : "");
location.append((lUri != null) ? lUri : "");
// XXX We are sending password as a GET and that might be logged somewhere
// on the server. Better to send it using POST. Perhaps using HttpClient?
I haven't looked into how standard the j_uri parameter is. It works from Resin and JBoss. We have to deploy to Oracle so I might have a check there too.
BTW, I'm working in Atlantic Quay for a few weeks.
I've found using the j_uri a bit flaky in the past (sometimes I'm logged in but redirected to a blank page!!). So I've moved over to using http://securityfilter.org/ and 'my' JBossRealmAdaptor - http://bladesys.demon.co.uk/roller/page/sradford/Weblog/20030712#jbossrealmadapter