[jira] Issue Comment Edited: (SHIRO-160) Flex integration with Shiro

["Bryan Turner (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SHIRO-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868378#action_12868378 ] 

Bryan Turner edited comment on SHIRO-160 at 5/17/10 4:07 PM:
-------------------------------------------------------------

Dave,

I don't think it can be a single Maven module, because the end result would be a single module with dependencies on both BlazeDS and GraniteDS, which will cause collisions on most if not all of the flex.* classes since both data service providers include their own versions of those classes. That would make the module more difficult to use, because developers would have to add an exclusion for the data service provider they're not using, and carefully wire in only classes related to the data service provider they are using. I think it would be best if it were split into at least 2, perhaps 3 modules. If there are classes you've written which do not rely on any Blaze-provided classes (meaning nothing in the flex.* packages as well as nothing in Blaze packages), those are the things that would go in support/amf. All of the Blaze-specific stuff should be moved to a support/amf/blazeds module.

The rest looks great. I might suggest dropping the DS from the names, though. I'd prefer BlazeLoginCommand and GraniteSecurityService--the DS just looks like noise.

      was (Author: bturner):
    Dave,

I don't think it can be a single Maven module, because the end result would be a single module with dependencies on both BlazeDS and GraniteDS. That would make the module more difficult to use, because developers would have to add an exclusion for the data service provided they're not using, and be careful to wire in only classes related to the service provider they're using. I think it would be best if it were split into at least 2, perhaps 3 modules. If there are classes you've written which do not rely on any Blaze-provided classes (meaning nothing in the flex.* packages as well as nothing in Blaze packages), those are the things that would go in support/amf. All of the Blaze-specific stuff should be moved to a support/amf/blazeds module.

The rest looks great. I might suggest dropping the DS from the names, though. I'd prefer BlazeLoginCommand and GraniteSecurityService--the DS just looks like noise.
  
> Flex integration with Shiro
> ---------------------------
>
>                 Key: SHIRO-160
>                 URL: https://issues.apache.org/jira/browse/SHIRO-160
>             Project: Shiro
>          Issue Type: New Feature
>          Components: Authentication (log-in), Authorization (access control) 
>    Affects Versions: Incubation
>            Reporter: david e. berry
>         Attachments: amf package layout.png
>
>
> Commiters,
> I have created the following classes that I used to integrate Shiro with Flex AMF. I would like to contribute them to the shiro. Please let me know if there is interest and the procedure for doing so. I have included the class names with a brief description of what they do. They are currently outside of the Shiro code base that I checked out, but I could combine them if interested.
> Best Regards,
> Dave 
> /* Authentication and Authorization need to let AMF Ping, Login, Logout messages pass through
> without processing. They call FlexMessageHelper to introspect the binary message to see if it is allowed to pass. 
> If not, normal Authentication, and Authorization takes place.
> */  
> public class FlexAuthenticationFilter extends AuthenticationFilter;
> public class FlexPermissionsAuthorizationFilter extends PermissionsAuthorizationFilter;
> public class FlexRolesAuthorizationFilter extends RolesAuthorizationFilter;
> /*Helper methods for introspecting the contents of the amf message. It is conceivable that a security handler
> might need to introspect the contents of a request. It would be nice if Shiro wrapped the request automatically so that anyone can read the contents without
> causing an end of stream error for a filter down the line. 
> Message helper deserializes the AMF message and checks to see if it is a PING, LOGON, or LOGOUT request. 
> */ 
> public class FlexHttpServletRequestWrapper extends HttpServletRequestWrapper;
> public class FlexMessageHelper;
> /* Custom Flex Login command that calls Subject.login returns a Principal back to Flex.
> */
> public class FlexLoginCommand implements LoginCommand;
> public class FlexPrincipal implements Principal;

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.