Getting rid of the j_security_check login page

[treespace]

We are using JAAS with form based login and j_security_check on our web application. We want users to login from the home page rather have them be intercepted when attempting to access a protected resource. We cannot put the j_security_check form on our home page because it appears it will only work as a intercept-and-forward action.

The intercept is great for bookmarking protected resources, for example, but we also want explicit login.

TIA

[j2ee_junkie]

treespace,

You want container managed authentication (i.e. you want to use FORM based authentication), but then you do not want the container to manage authentication. Pick one.

if you still need advice, form a question. Have a great day, cgriffith

[treespace]

I want to invoke the magic login action with an explicit call. I want the container to manage authentication just as always does. That is what users want and in general how authentication is implemented on websites. I don't see how allowing an explicit authentication call suddenly invalidates form-based login. That's a false choice that only inconveniences users.

[brian.stansberry]

If I understand correctly what you want, you can do this kind of thing with an AJAX call. Collect the form inputs, use XMLHttpRequest to request a secured page, use XMLHttpRequest to post the inputs to j_security check. You now have an authenticated session. Now direct the browser to wherever you want the user to go.

[treespace]

Posting to j_sercurity_check is not allowed, AFAIK. The container wants to forward the request to the original target.

Consider the "remember me" login feature. J2ee_junkie says that you have to ditch form-based login if you need that feature. I think he's high:)

[j2ee_junkie]

treespace,

FORM based authentication is specified to work as you call it "intercept-and-forward". When a request is made to a secured resource, and the session has no authenticated principal, the request is saved, and user is forwarded to login page. When the container receives another request by same session, and that request is the 'j_security_check', then user credentials are passed to realm to authenticate. If credentials are authenticated, then the orginal request is restored, and user is forwared to it. That is if they have the roles to access it.

If your main page has a form that posts to 'j_security_check', then what will happen is that the user credentials will be passed to realm as above. If credentials are authenticated, then the orginal request is restored, and user is forwarded to it. But wait, there is no orginal request. So the what should the container do? It returns null response.

So if you want to use FORM based authentication the way you want, you have to get creative! I have never done this, so I do not know if it would work, but I would suggest...

1 make your main page secured by adding a security-constraint for it in your web.xml.

2 set your auth-method to FORM

3 set your form-login-page to your main page

I would think what should happen is that a user attempts to access your application and is intercepted by FormAuthenticator, request is saved, and user is redirected to your main page. If the user submits to 'j_security_check' then the authenticator will do it's authentication thing. If user is authenticated, then they will be forwarded back to orginal request.

There may be a problem with this if user delays too long before submitting to 'j_security_check'. If you try this, please let us know in detail what happens. Other than that, I am not sure how to bend FORM auth. to fit your needs. But understand, you must bend it somehow.

again, let us know, cgriffith

p.s. I am high. Being able to do what we do, makes me high.

[treespace]

I understand the current behavior and it is working well. Keep in mind we are only looking to keep that behavior but extend it with one extra feature: programmatic login.

I have an idea based on your's and Brian's input. I will report back with results.