Kalle,
How authentication failures are displayed to the user is generally
application specific. Usually applications catch
AuthenticationException or some of its subclasses if more granular
reporting is required. They then translate those exceptions into a
validation message and display it to the user. Also, for security
reasons, it's generally not a good idea to tell the user whether they
entered a non-existant username or an incorrect password.
The simplest example may look like this:
try {
subject.login(...);
} catch (AuthenticationException e) {
// Add something to the request to communicate the login
failure to the user
}
You could add additional catch blocks above the
AuthenticationException to catch different subclass exceptions and
give more specific error messages.
To obtain the originally requested URL from Ki, call
WebUtils.getSavedRequest(...) which will give you back a SavedRequest
object describing the original request. This can be used to redirect
after login.
If you do not want Ki to do the authentication for you, but would
rather execute it in your web framework, you can change the "authc"
filter to pass-thru requests to your web framework. In this case, Ki
assumes that you will handle the authentication yourself which sounds
like the behavior you are after. To get this to work, add the
following line to the [filters] section of your Ki configuration:
authc = org.jsecurity.web.filter.authc.PassThruAuthenticationFilter
(package name above changes to "ki" if you are using the trunk version)
Please let me know if you have any problems or further questions!
Jeremy
On Apr 6, 2009, at 2:04 AM, Kalle Korhonen wrote:
Is there a standard/recommend way in JSecurity/Ki to make the reason
for an
authentication failure available to the application? Similarly to
CMA, if Ki
is configured to run before the application servlet/filter, there's no
direct way to tell the application why an authentication try failed.
Is the
recommended mechanism in this case to try to use a standard
"<error-page><exception-type>" element in web.xml or something else?
The
other way around, if I create a login form and handle the
authentication in
it myself (by calling SecurityUtils.getSubject().login() ) is there
a way to
obtain the "originally requested url" from Ki that the security filter
intercepted, then redirected to login page?
Currently I implemented this so that a login form that *could*
handle login,
but a success case is directly handled by Ki. In a failure case, Ki
let's
the request through and I just re-try the authentication to get the
failure
reason. This is a little hackish and results in an unnecessary
authentication try in a failure case, but works surprisingly well
for me as
it allows me to use the "native" error message mechanisms of my web
application framework.
Kalle
