SecureCommandConfigurer

[markash]

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.

[Keith Donald]

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

[adepue]

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

[Keith Donald]

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.

[Ben Alex]

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?

[adepue]

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

[Ben Alex]

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.