The catching AuthenticationException and returning false is something
I'm not familiar with. I don't think I've mentioned it? Please refresh
my memory, maybe I have mentioned it. ;-)

I was talking about Spring throwing a
AuthenticationCredentialsNotFoundException, when the exception goes
back to Wicket it swallows the exception (and shows it to the user)
and I was wondering if there is a possibility to let that specific
exception through. By letting it through (ie re-throwing it without
encapsulating it or modifying it) Spring can handle it and I think it
will work as advertised by Spring.

My question 2 was essentially if this is something one wants to do
with Wicket. Or if there could be any nasty surprises along the way?

One such nasty surprise might be:

1. Spring records the request.
2. Wicket recieves the request, it's a session relative page.
3. Wicket does its thing and some logic written by "you" is executed.
4. Your code calls a Spring bean through Wicket-Spring-IoC.
5. Spring Security intercept the method call and performs an
authrorization check. It turns out the user isn't logged in! A
AuthenticationCredentialsNotFoundException is thrown.
6. Wicket catches the AuthenticationCredentialsNotFoundException but
re-throws it exactly as it were (by solving my question 1).
7. Spring catches the exception, let's the user log in and simulates
the previously recorded request.
8. The request is for the session relative page from earlier [see 2
above]. But that object no longer exists as the
AuthenticationCredentialsNotFoundException was thrown [see 5 above].
Maybe we will get a NullPointerException here.

Could such nasty surprises happen? If so, then it might be better to
turn the user to a access denied page when a @Secured method is found
and the user isn't logged in or lacks the sufficient role(s). It still
involves catching the Spring Security exception I guess, but logging
in and re-sending the request is not an option.

Thoughts?

Best regards, Kent




On Thu, May 14, 2009 at 7:46 PM, James Carman
<jcar...@carmanconsulting.com> wrote:
> On Thu, May 14, 2009 at 1:38 PM, Kent Larsson <kent.lars...@gmail.com> wrote:
>> Hi James,
>>
>> Thank you for example! Although I can't find any secured methods in
>> there. Not in your beans.xml and not by grepping for Secured on all
>> your files. So correct me if I'm wrong, but I don't think you are
>> using the method security option in Spring Security? In any case I'm
>> greatful for you showing me how you solved the integration and I'll be
>> looking more into it soon.
>>
>> My current problem is with method security, while URL security works.
>
> You're very welcome.  Sorry I didn't fix the problem in the code (I
> should do that while I'm thinking about it), but it's not that
> difficult to catch AuthenticationException and return false.  You're
> correct, I am not using method-level security.  I can imagine that you
> can try a custom error catcher to redirect to your login page if a
> spring security exception is found (or tell them they're not allowed
> to do what they tried to do)?  I'd have to play with it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to