You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Kent Larsson <ke...@gmail.com> on 2009/05/06 19:25:08 UTC
Spring Security's method security and Wicket
Hi,
I'm having some trouble getting method security to work as expected
using Spring Security together with Wicket, I have a thread about it
over at the SpringSource forum:
http://forum.springsource.org/showthread.php?t=71397 .
Basically I have this situation:
1. Unauthenticated user submits a form, the onSubmit method calls a
method in a Spring singleton which is secured using method security by
a @Secured("NON_EXISTING_ROLE") annotation.
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.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by James Carman <jc...@carmanconsulting.com>.
Kent,
You can svn update my wicket-advanced example. It's got the code in it.
On Mon, May 18, 2009 at 8:24 AM, Kent Larsson <ke...@gmail.com> wrote:
> It sounds very interesting! If you would like to share it some day I
> would be curious to know how you did it. Why do you consider it not
> complete if it's not possible to do it any better due to how Wicket
> handles redirectToInterceptPage?
>
> Best regards, Kent
>
>
> On Fri, May 15, 2009 at 7:17 PM, James Carman
> <jc...@carmanconsulting.com> wrote:
>> On Fri, May 15, 2009 at 8:24 AM, Kent Larsson <ke...@gmail.com> wrote:
>>> Sounds like a nicer solution!
>>>
>>> I'll look into doing something like that myself, being a Wicket newbie
>>> it might take me a while though. Are there any examples of doing
>>> anything similar available somewhere?
>>
>> Well, I've got a working solution, but it's not quite complete, IMHO.
>> I've got it redirecting to the login page whenever you try to invoke a
>> @Secured method. But, once you login, it doesn't exactly go back and
>> try to do what you were trying to do. It will just take you back to
>> the page where you were trying to do it (a limitation of how Wicket
>> handles the redirectToInterceptPage). My solution uses an aspect to
>> enforce the @Secured annotations.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by Kent Larsson <ke...@gmail.com>.
It sounds very interesting! If you would like to share it some day I
would be curious to know how you did it. Why do you consider it not
complete if it's not possible to do it any better due to how Wicket
handles redirectToInterceptPage?
Best regards, Kent
On Fri, May 15, 2009 at 7:17 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> On Fri, May 15, 2009 at 8:24 AM, Kent Larsson <ke...@gmail.com> wrote:
>> Sounds like a nicer solution!
>>
>> I'll look into doing something like that myself, being a Wicket newbie
>> it might take me a while though. Are there any examples of doing
>> anything similar available somewhere?
>
> Well, I've got a working solution, but it's not quite complete, IMHO.
> I've got it redirecting to the login page whenever you try to invoke a
> @Secured method. But, once you login, it doesn't exactly go back and
> try to do what you were trying to do. It will just take you back to
> the page where you were trying to do it (a limitation of how Wicket
> handles the redirectToInterceptPage). My solution uses an aspect to
> enforce the @Secured annotations.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by James Carman <jc...@carmanconsulting.com>.
On Fri, May 15, 2009 at 8:24 AM, Kent Larsson <ke...@gmail.com> wrote:
> Sounds like a nicer solution!
>
> I'll look into doing something like that myself, being a Wicket newbie
> it might take me a while though. Are there any examples of doing
> anything similar available somewhere?
Well, I've got a working solution, but it's not quite complete, IMHO.
I've got it redirecting to the login page whenever you try to invoke a
@Secured method. But, once you login, it doesn't exactly go back and
try to do what you were trying to do. It will just take you back to
the page where you were trying to do it (a limitation of how Wicket
handles the redirectToInterceptPage). My solution uses an aspect to
enforce the @Secured annotations.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by Kent Larsson <ke...@gmail.com>.
>> 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. ;-)
>
> It would be in the authenticate method of mine. If the exception is
> thrown, you'd need to return false.
Ah, I'll check it out. :-)
>> 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.
>
> I don't think I'd have Spring catch the exception. I'd use a custom
> RequestCycle and put logic in it to look for those runtime exceptions.
> If it sees one, it'd either redirect the user (by throwing a restart
> at intercept page exception) if they're not logged in or show the
> "you're not allowed to do that" page.
Sounds like a nicer solution!
I'll look into doing something like that myself, being a Wicket newbie
it might take me a while though. Are there any examples of doing
anything similar available somewhere?
Best regards, Kent
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by James Carman <jc...@carmanconsulting.com>.
On Fri, May 15, 2009 at 5:02 AM, Kent Larsson <ke...@gmail.com> wrote:
> 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. ;-)
It would be in the authenticate method of mine. If the exception is
thrown, you'd need to return false.
> 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.
I don't think I'd have Spring catch the exception. I'd use a custom
RequestCycle and put logic in it to look for those runtime exceptions.
If it sees one, it'd either redirect the user (by throwing a restart
at intercept page exception) if they're not logged in or show the
"you're not allowed to do that" page.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by Kent Larsson <ke...@gmail.com>.
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
<jc...@carmanconsulting.com> wrote:
> On Thu, May 14, 2009 at 1:38 PM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by James Carman <ja...@carmanconsulting.com>.
That example should be self-contained. I'm going to play around with
method-level stuff tonight hopefully. I'm curious myself.
On May 14, 2009 6:51 PM, "freak182" <em...@gmail.com> wrote:
Hi James,
Can you share your wicket-spring-security project or there is already in
wicketstuff?
Thanks a lot.
Cheers.
James Carman-3 wrote: > > On Thu, May 14, 2009 at 1:38 PM, Kent Larsson
<kent.larsson@gmail.com...
> --------------------------------------------------------------------- > To
unsubscribe, e-mail: us...
View this message in context:
http://www.nabble.com/Spring-Security%27s-method-security-and-Wicket-tp23411667p23550461.html
Sent from the Wicket - User mailing list archive at Nabble.com.
--------------------------------------------------------------------- To
unsubscribe, e-mail: user...
Re: Spring Security's method security and Wicket
Posted by freak182 <em...@gmail.com>.
Hi James,
Can you share your wicket-spring-security project or there is already in
wicketstuff?
Thanks a lot.
Cheers.
James Carman-3 wrote:
>
> On Thu, May 14, 2009 at 1:38 PM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Spring-Security%27s-method-security-and-Wicket-tp23411667p23550461.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by James Carman <jc...@carmanconsulting.com>.
On Thu, May 14, 2009 at 1:38 PM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by Kent Larsson <ke...@gmail.com>.
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.
If I secure an URL using Spring Security it works as it should (I get
re-directed to the login page if I'm not logged in, or to the access
denied page if I am logged in). I think it works because the Spring
filter comes before the Wicket filter. When the
AuthenticationCredentialsNotFoundException (from Spring) is thrown
from Spring's code it will also be processed by the Spring code.
On the other hand. If the call reaches Wicket's filter and gets
processed by Wicket and my own code and a
AuthenticationCredentialsNotFoundException (from Spring) is thrown
then Wicket will also deal with it and the Spring filter will never
know what happened.
I currently have two questions:
1. I would like any AuthenticationCredentialsNotFoundException to pass
through Wicket's filter so it may be processed by the Spring filter.
Any ideas? I suspect it might be doable by creating and using my own
request cycle [ by extending WebRequestCycle) and overriding
onRuntimeException(..) ] but as I'm quite new to Wicket I'm a bit
unsure of how that is done.
2. In these cases (when a AuthenticationCredentialsNotFoundException)
is raised it will result in the method call failing and transaction
rollback. As Spring has "recorded" the request it will "replay" it
when the user has authenticated. Any thoughts about this and how it
will work with: bookmarkable pages, session relative pages and back
button functionality?
Best regards, Kent
On Fri, May 8, 2009 at 12:53 PM, James Carman
<jc...@carmanconsulting.com> wrote:
> You can check out my wicket-advanced application that I wrote for a
> talk I gave to our local Java users group. In there, I implemented a
> Spring Security-based implementation. Here's my session class:
>
> http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/java/com/carmanconsulting/wicket/advanced/web/common/session/SpringSecuritySession.java
>
> and here's my application class:
>
> http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/java/com/carmanconsulting/wicket/advanced/web/common/application/WicketApplication.java
>
> and here's my web configuration:
>
> http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/webapp/WEB-INF/web.xml
>
> and here's my spring configuration:
>
> http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/resources/META-INF/beans.xml
>
> It works, but I believe someone pointed out a little bit of a bug in
> my code at one point. I don't think I fixed it yet. I can't remember
> who it was. Anyone? Perhaps it was something about not catching the
> authentication exception in the login and returning false? I can't
> remember. :(
>
>
> On Fri, May 8, 2009 at 5:51 AM, Kent Larsson <ke...@gmail.com> wrote:
>> 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 <ke...@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 <ig...@gmail.com> wrote:
>>>> On Wed, May 6, 2009 at 10:25 AM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by James Carman <jc...@carmanconsulting.com>.
You can check out my wicket-advanced application that I wrote for a
talk I gave to our local Java users group. In there, I implemented a
Spring Security-based implementation. Here's my session class:
http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/java/com/carmanconsulting/wicket/advanced/web/common/session/SpringSecuritySession.java
and here's my application class:
http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/java/com/carmanconsulting/wicket/advanced/web/common/application/WicketApplication.java
and here's my web configuration:
http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/webapp/WEB-INF/web.xml
and here's my spring configuration:
http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/resources/META-INF/beans.xml
It works, but I believe someone pointed out a little bit of a bug in
my code at one point. I don't think I fixed it yet. I can't remember
who it was. Anyone? Perhaps it was something about not catching the
authentication exception in the login and returning false? I can't
remember. :(
On Fri, May 8, 2009 at 5:51 AM, Kent Larsson <ke...@gmail.com> wrote:
> 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 <ke...@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 <ig...@gmail.com> wrote:
>>> On Wed, May 6, 2009 at 10:25 AM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by Kent Larsson <ke...@gmail.com>.
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 <ke...@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 <ig...@gmail.com> wrote:
>> On Wed, May 6, 2009 at 10:25 AM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by Kent Larsson <ke...@gmail.com>.
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 <ig...@gmail.com> wrote:
> On Wed, May 6, 2009 at 10:25 AM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, May 6, 2009 at 10:25 AM, Kent Larsson <ke...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Spring Security's method security and Wicket
Posted by James Carman <jc...@carmanconsulting.com>.
On Wed, May 6, 2009 at 1:25 PM, Kent Larsson <ke...@gmail.com> wrote:
> Hi,
>
> I'm having some trouble getting method security to work as expected
> using Spring Security together with Wicket, I have a thread about it
> over at the SpringSource forum:
> http://forum.springsource.org/showthread.php?t=71397 .
>
> Basically I have this situation:
> 1. Unauthenticated user submits a form, the onSubmit method calls a
> method in a Spring singleton which is secured using method security by
> a @Secured("NON_EXISTING_ROLE") annotation.
> 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.
>
> 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! ;-)
I don't usually use spring security in that way with Wicket. I use
wicket-auth-roles and the annotations it comes with to secure at the
page/component level.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org