Re: Spring Security's method security and Wicket
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 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 > wrote: >> On Fri, May 15, 2009 at 8:24 AM, Kent Larsson 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-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
Re: Spring Security's method security and Wicket
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 wrote: > On Fri, May 15, 2009 at 8:24 AM, Kent Larsson 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-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
Re: Spring Security's method security and Wicket
On Fri, May 15, 2009 at 8:24 AM, Kent Larsson 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring Security's method security and Wicket
>> 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring Security's method security and Wicket
On Fri, May 15, 2009 at 5:02 AM, Kent Larsson 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring Security's method security and Wicket
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 wrote: > On Thu, May 14, 2009 at 1:38 PM, Kent Larsson 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
Re: Spring Security's method security and Wicket
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" 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 - > 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
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 > 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 > > > -- 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring Security's method security and Wicket
On Thu, May 14, 2009 at 1:38 PM, Kent Larsson 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
Re: Spring Security's method security and Wicket
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 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 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 wrote: >
Re: Spring Security's method security and Wicket
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 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 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 >> wrote: >>> On Wed, May 6, 2009 at 10:25 AM, Kent Larsson >>> 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 > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional co
Re: Spring Security's method security and Wicket
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 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 wrote: >> On Wed, May 6, 2009 at 10:25 AM, Kent Larsson 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
Re: Spring Security's method security and Wicket
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 wrote: > On Wed, May 6, 2009 at 10:25 AM, Kent Larsson 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
Re: Spring Security's method security and Wicket
On Wed, May 6, 2009 at 10:25 AM, Kent Larsson 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
Re: Spring Security's method security and Wicket
On Wed, May 6, 2009 at 1:25 PM, Kent Larsson 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org