Question regarding flex:secured

[hdave]

The documentation is not clear on something. If I just put

<flex:secured />

Within <flex:message-broker> What happens?

I know can put:

<flex:secured-channel channel="my-amf" />

But when happens if I leave these out? Will all channels be secured by default? or no channels?

[tmoens]

I believe this just enables spring security. You can now issue channelSet.login(uid,pwd) and channelSet.logout() commands in the client.

Section 5.3 of the documentation for 1.5.0.M1 tells you all about the various ways you can secure access to your server so that unauthorized access is blocked. You can secure whole channels (as you said), URLs or services down to the individual method. Just today I learned how to do this with pointcuts (5.3.3) and it works a charm.

If you want to use @Secured annotations on the server to secure individual methods please note that by default, you can only use @Secured on interfaces. After struggling for a while on this earlier, I was told "when annotating classes rather than interfaces with the @Secured annotation, you need to be sure to have Spring AOP configured to use CGLIB proxies rather than the default Java dynamic proxies." At the time I had no clue how to do that so I used my IDE to extract interfaces for my services and then annotated the interfaces. Worked fine.

If you happened to use the flex add-on for Roo to generate your services, all the methods are in the .aj files which are generated and you can not edit them (without losing the edits) and therefore you cannot annotate the methods with @Secured. Too bad. This is when you really read section 5.3.3 and learn how to put <protect-pointcut>... in your security context file.

Hope this helps,

Ted

[jeremyg484]

If you happened to use the flex add-on for Roo to generate your services, all the methods are in the .aj files which are generated and you can not edit them (without losing the edits) and therefore you cannot annotate the methods with @Secured. Too bad. This is when you really read section 5.3.3 and learn how to put <protect-pointcut>... in your security context file.

Keep in mind that you are free to implement any of the Roo-generated methods yourself in the actual .java file for the service, i.e., in Roo vernacular, you "take control" of that method. The easiest way to do that is to use STS's push-in refactoring feature. At that point, you should be able to add a @Secured annotation as necessary.

That said, I can see how it would be nice to have a way to indicate security permissions on one of these methods without having to take control of it. I've gone ahead and created a Jira to capture that:
https://jira.springframework.org/browse/ROOFLEX-21

Feel free to comment there with any additional insights on how you'd like it to work.

[BrianBLong]

This thread was a huge help to me I'm rushing through the reference docs to just get an app pushed out quickly (note that I'm new to both Flex and Spring) and I did not realize the annotation needed to be on the interface.

Is there any way we can mark that as a bug? I know the @Secured annotation will not compile without having a value, i.e. @Secured("ROLE_ADMIN") but it does not if the annotation is added to a method in a concrete class?

[jeremyg484]

It's really not a bug, it's just a known and accepted difference in behavior when using Spring AOP with JDK dynamic proxies (the default, where proxies may only be applied to interfaces) versus CGLIB based proxies.

One thing I did just do in M2 is add a note to the docs that points out this difference and links to the appropriate sections of the Spring documentation for further detail. See the note here:
http://static.springsource.org/sprin...g-destinations

[BrianBLong]

One thing I did just do in M2 is add a note to the docs that points out this difference and links to the appropriate sections of the Spring documentation for further detail.

Thanks Jeremy, I definitely appreciate it. I think it was one of those things that I just sort of glanced over as a Spring newcomer. Learning it by mistake means I won't soon forget it though! Cheers