Announcement Announcement Module
Collapse
No announcement yet.
SecureCommandConfigurer Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SecureCommandConfigurer

    Good Day,

    SecureCommandConfigurer receives the login and logout events but does not update the commands as yet (a big TODO in the code).

    Could you please let me know how rcp intends to handle this and I could look at implementing it for you.

  • #2
    The SecureCommandConfigurer should most likely be obsoleted. In general, I think the commands themselves should react to LoginEvents and disable themselves accordingly. We need to look at providing an AbstractSecureActionCommand or similiar action to make this easy.

    Keith

    Comment


    • #3
      Along these same lines, we have the requirement that some secured commands should simply not be visible (as opposed to not enabled)... would it make sense to add visibility to Guarded?

      - Andy

      Comment


      • #4
        I think this would particularly useful for subclasses of CommandGroup - e.g a SecureCommandGroup subclass, which knowledge about the current user and the roles required for this group to be enabled and visible.

        Comment


        • #5
          Just curious..... What remoting protocol are most Spring Rich clients using? I've added to Acegi Security core CVS two "better" integrations with remoting protocols than RemotingSecurityConfigurer. Now HttpInvoker and RMI invocations will automatically populate themselves with the ContextHolder-derived username and password (or the entire ContextHolder in RMI's case) at each invocation time. But are people using these protocols primarily, or others?

          Comment


          • #6
            Ben,
            For now I'm using HttpInvoker (actually, I'm using a modified form of HttpInvoker, see this thread: http://forum.springframework.org/sho...d.php?t=10753= ). What I've done is created an interface "AuthorizationAware" that any bean (including bean factories, such as my BasicAuthHttpInvokerProxyFactoryBean) can implement. If a bean in the application context implements this interface then it will be automatically injected with authorization information whenever the user logs in or out. This separates my invoker from any kind of security implementation (such as Acegi), and is slightly easier to use than application events.

            - Andy
            Last edited by robyn; May 14th, 2006, 05:14 PM.

            Comment


            • #7
              Hi Andy, an interesting approach. I just added a comment to that thread showing Acegi Security's approach to HttpInvoker extension. I think I'll soon add an interceptor which takes a list of classnames, expecting each class to provide a setUsername and setPassword method. At invocation time it will scan the IoC container for any instances, setting calling the respective setters based on the contents of the ContextHolder. This should eliminate the need for the SecureCommandConfigurer entirely.

              Comment

              Working...
              X