When you use a Realm and the web.xml security definitions, you're employing
J2EE standard container-manages Authentication and Authorization. This is a pretty well-documented system and it's fairly simple, but extremely effective. It's also extremely secure, which is something that I haven't seen much of in "do-it-yourself" security systems.
You should NEVER tell a user "incorrect password". That tells them that they know the userid, so they only have to work half as hard to break in. That's why really secure systems will only say "invalid user id/password". It keeps the Bad Guys guessing. Security is the one place where being helpful is not a virtue.
web.xml allows to define both a login view and a loginfail view. Loginfail is - not surprisingly - what displays when you enter credentials on the login page and they are not correct. Usually my loginfail pages are identical to the login pages and contail a j_username and j_password form just like the login page, but usually have the caption "Login failed" on them. Which is as close as I'll get to saying "Invalid Password".
The login/loginfail pages aren't actually managed by the webapp. They're managed by the webapp container. As a result, they have certain limitations and should be kept simple. And yes, the login action processor for the container does expect a form with fields named "j_username" and "j_password" exactly as spelled/capitalized.
J2EE doesn't route a user after login for a number of reasons. One of the primary strengths of the J2EE security system is that it acts as wrap-around protection for the webapp URLs. One of the most common ways to exploit do-it-yourself security is by submitting a URL that bypasses the DIY security. In J2EE security, NOTHING bypasses security. The URL will never reach the webapp at all unless the user is authenticated and authorized. Since the container doesn't route post-login actions, this allows a secure direct access to commonly-used pages. It also factors in when you're using a site-wide security system instead of a per-application security context. In such cases, you might have logged in to another app entirely, so this app would never actually see a login event. And no, there's aren't any J2EE login/logout events
per se. precisely because of such considerations. If you must, you can fake it. put a filter in the webapp and monitor the incoming HttpRequests for a change in the userid property. You've just logged in when the userid is no longer null. "Logout" detection, of course, is done by employing a Session Listener to detect Session destroy events.
