j_security_check login

[Wesley Baker]

Not sure if this is the right forum - couldn't find another that fit better, though.

I am using a JDBCRealm on Glassfish for Form based authentication. Everything is working peachy. I have noticed some odd things though that are causing me some headaches:

1) A strange "feature" of the j_security_check login process is that if you go directly to the login page and log in successfully, it will simply refresh the login page. Redirection is only automatic if the user is trying to get to a page behind the security constraints. So in my attempt to write the redirection code myself, I came across problem #2...

2) request.getUserPrincipal() is always null, even after a successful login. I did many Google searches on this, but all I can find is a whole bunch of people having the same problem and no one has an answer. So my question is, how else can I figure out whether someone is logged in or not?

Basically, I am trying to figure out if someone has logged in or not, so that when they visit the login page directly, it will look up their group association and direct them to the proper page.

All suggestions welcomed!

[Ulf Dittmer]

As to #1, that's just how servlet form authentication works. The main entry point should not be the login page, but the main -protected- page behind it. Trying to access that page will make a detour through the login page if necessary. I don't think it's ideal, either, but then, the Servlet API-provided security mechanism suffices only for simple scenarios anyway IMO. So for all "serious" web apps I've gone with hand-rolled user and login management instead of the built-in stuff.

As to #2, I've never tried getUserPrincipal, so I can't speculate on why it's not working. The reason is that I never saw the need to get a Principal object - getting the username and its associated roles was always sufficient. Those are provided by the getRemoteUser and isUserInRole methods.

[Carey Evans]

getUserPrincipal() (and getRemoteUser()) will return null if the servlet that's checking isn't matched by a <url-pattern> in the security constraints. You might need to enable security for more than just your main page.