Hello,
Reference for this post:
http://forum.springsource.org/showthread.php?p=239559#post239559 (the
related Spring Security thread)
It actually seems my interpretation about how it might work was
correct below (though my original interpretation was wrong, but let's
not talk about that one ;-) ).
Luke Tayler mentions it might be Wicket swallowing the exception which
Spring Security creates and shows it to the user. That way Spring
Security will never know that the exception was thrown and it can't
redirect the user to the log in page.
What Spring Security seems to like doing is:
1. Spring Security records the request data.
2. When a @Secured("SOME_ROLE") annotated method is found it throws a
AuthenticationException or a AuthorizationException
3. This exception is cought by Spring Security which redirect the user
to the log in page.
4. When the user has logged on, the recorded request data is used
again to simulate the original request.
At step 2 above any transaction is rolled back.
Between step 2 and 3, at step 2.5 it seems Wicket catches the
AuthenticationException or AuthorizationException and (at least in
development mode) shows the exception to the user. That way step 3 and
4 will never be executed.
Between step 1 and 2, at step 1.5 above Wicket will do its stuff
(page, models, etc). If the same (recorded) request arrives again
(after user log in) how will Wicket react?
Is it possible to get this working with Wicket? Should I? Any tips?
I'm new to both Wicket and Spring Security, this might be a bit over
my head. It would be really nice to get it working though. Thank you
for reading! Have a nice weekend!
Best regards, Kent
On Wed, May 6, 2009 at 10:22 PM, Kent Larsson <kent.lars...@gmail.com> wrote:
> I don't know. I guess something like:
>
> 1. "Record" the request data (like with URL interception) then let the
> method call fail & roll-back transactions
> 2. Show log in page
> 3. Play the recorded request and hope the call was determenistic
>
> But maybe I just misinterpreted him. Or maybe it would work with
> Spring MVC if they have this built into their architecture. But it
> sounds strange so I understand why you ask.
>
> Best regards, Kent
>
>
> On Wed, May 6, 2009 at 7:46 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
>> On Wed, May 6, 2009 at 10:25 AM, Kent Larsson <kent.lars...@gmail.com> wrote:
>>> 2. At this point, the method call is intercepted by Spring and I
>>> _think_ I should get the option to log in here. However I do not get
>>> this option, instead I'm shown a stack trace.
>>
>> how is (2) accomplished?
>>
>> -igor
>>
>>
>>>
>>> I'm really banging my head against the wall here. I just wanted to ask
>>> here if this could have anything with the Wicket-Spring-IOC project?
>>>
>>> I would suspect no and that I'm to blame, but I'm also having a really
>>> hard time finding the source of the problem. If you have any tip for
>>> my as well I would really appreciate it! ;-)
>>>
>>> Best regards, Kent
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
