Modifying j_username before calling j_security_check

[anodos]

I know this comes up a lot, but after searching around, I haven't found any good answers. Basically, we have three requirements:
1. Since we may deploy to different J2EE containers, we cannot use container specific extensions (though we are using JBoss for development).
2. We must use servlet spec authentication. This means j_security_check
3. We have to modify the username that the user enters before submitting to j_security_check.

I think it might be possible by posting to our own .jsp, doing the username modification, and then using redirect to j_security_check, but then the username and password would be encoded in the URL, which leaves a bad taste in my mouth. We have already tried "forward", but that just doesn't work (we tried this on the latest development release of JBoss 4) - Tomcat gives us a 404. The other option would be to use HttpClient and POST to j_security_check. We haven't tried this yet, but I did see one person who suggested in this forum. Has anyone tried this approach? How did you handle forwarding the client to the page they were intending to reach after POSTing to j_security_check via HttpClient (since HttpClient will receive the redirect, not your client's browser)? Does this even work, or will Tomcat croack on this approch as well?

Thanks,
Anodos

[wdrai]

Have you tried with a servlet filter which intercepts the j_security_check call ?

[ant]

I have tried using a servlet-filter in order to do pre- and post-processing to j_security_check but it didn't work. There are some other people reporting that filtering j_security_check isn't possible.

Also using a custom loginmodule isn't possible because of caching security information (see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=47640).

Gerd

[starksm64]

The only way you will be able to do this then is with javascript on the client side as there is no standard mechanism to pre process the form post on the server side.

[anodos]

We have tried the 'redirect' option, and it works with JBoss 4 / Tomcat 5, though we have not tried it with other containers. Again, we do not prefer this option as it encodes the username and password on the URL (though we do SHA1 the password before it is put onto the URL). For now, we can continue with development, and at a later time will try using HttpClient with POST.