FormAuthenticationFilter configuration issue

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FormAuthenticationFilter configuration issue

Les Hazlewood-2
Hi guys,

We recently got an issue http://issues.jsecurity.org/browse/JSEC-123 that
caused me to think a little.

It turns out the following configuration will cause all login submissions to
go back to the same page, without a login ever being executed.

[filters]
jsecurity.loginUrl = /login.jsp

[urls]
/account/** = authc
/remoting/** = authc, roles[b2bClient], perms[remote:invoke:"lan,wan"]

Well, technically, the login submission goes to wherever the form action=""
attribute is set to.  But in our examples, that action attribute is always
empty (""), telling the browser to submit to the current url.

This is how our current quickstart is configured, and it will fail.

Anyway, the reason why this fails is that the 'authc' filter is never
invoked, because it is never specified in the [urls] mappings to be used for
that url.

To get it to work, you have to do the following:

[filters]
jsecurity.loginUrl = /login.jsp

[urls]
# The /login.jsp is not restricted to authenticated users (otherwise no one
could log in!), but
# the 'authc' filter must still be specified for it so it can process that
url's
# login submissions. It is 'smart' enough to allow those requests through as
specified by the
# jsecurity.loginUrl above
*/login.jsp = authc*
/account/** = authc
/remoting/** = authc, roles[b2bClient], perms[remote:invoke:"lan,wan"]

But, this seems a tad off to me - if they specify

jsecurity.loginUrl = /login.jsp

one would assume that this will be handled automatically.

But because the login url is not guaranteed to be handled by our authc form
filter, e.g. because the user wants to use the passThru filter instead, we
can't do automatic setup for this.  I don't know if there is another way,
and wanted to see if you had any ideas.  Otherwise, the issue is considered
resolved because it is solved via configuration, not by a code change.
Loading...