How to hide a menu (or something) in a spring rich client application?

[felipecomp19]

Hi everyone,

I'm trying to hide a item from a menu in my application considering the permissions ( the "ROLE_") of the user.

An example:

I want to hide the option "Property" of the "Tools" menu in my application if the "ROLE" of the user is different of "ROLE_ADMIN".

I've discovered how to intercept the method that "open" the "Property" wizard, but I don't know how to hide this... Get it? Can some one help me with this?

I'm using a LDAP server for authentication and authorization.

please, help me...

[morb]

This hides the menu item and toolbar button of a specific command:

TargetableActionCommand cmd = (TargetableActionCommand) Application.instance().getActiveWindow().getCommandManager().getCommand("xyCommand");
cmd.setVisible(false);

[adamarmistead]

If you are looking for a more spring like configurable way to manage this you can configure some UserRoleSecurityControllers and register them in a SecurityControllerManager.

<!--
  Bean: adminController
  Usage: Optional
  Description:  The admin controller authorizes objects registered with it for use by users with the admin role.

    A security controller is any object that controls Authorizable objects. The security controller is
    responsible for reacting to changes in the application state (typically the user's authentication) and
    then making a decision to authorize or not authorize the objects regsitered with the controller.
-->
<bean id="adminController"
  class="org.springframework.richclient.security.support.UserRoleSecurityController">
  <property name="authorizingRoles" value="ROLE_ADMIN"/>
  <property name="postProcessorActionsToRun" value="visibleTracksAuthorized"/>
</bean>

<!--
  Bean: fallbackController
  Usage: Optional
  Description:  The fallback controller authorizes objects registered with it for use by users with the
    the user role.

    A security controller is any object that controls Authorizable objects. The security controller is
    responsible for reacting to changes in the application state (typically the user's authentication) and
    then making a decision to authorize or not authorize the objects regsitered with the controller.
-->
<bean id="fallbackController"
    class="org.springframework.richclient.security.support.UserRoleSecurityController">
  <property name="authorizingRoles" value="ROLE_USER" />
</bean>

<!--
  Bean: securityControllerManager
  Usage: Optional
  Description:   The SecurityControllerManager allows you to specify a map of aliases for security controllers.
    This is where you register the command security controller id and the proper security controller to handle it.

    When commands are created dynamically, which is the case for a lot of commands used in forms,
    there needs to be a way to declare the security controller responsible for handling them. This is done
    (via the SecurityControllable interface) by specifying the securityControllerId on the command. The
    various form classes provide default security controller ids for the commands they create. The general
    pattern of the id is <form id>.<command face id>.
-->
<bean id="securityControllerManager"
  class="org.springframework.richclient.security.support.DefaultSecurityControllerManager">
  <property name="fallbackSecurityController" ref="fallbackController"/>
  <property name="securityControllerMap">
    <map>
      <entry key="propertyCommand" value-ref="adminController"/>
    </map>
  </property>
</bean>

You would need to specify a securityControllerId for your Property command.

<bean id="propertyCommand"
  class="com.my.app.commands.PropertyCommand">
  <property name="securityControllerId" value="adminController"/>
</bean>

And don't forget, if you are creating your commands programmatically, you need set the security controller id and have them configured by the command configurer. I seem to remember I also had to explicitly set the authorized property to true before configuring them, or they would end up not being authorized when they should have been on application startup, or something like that anyway.

ActionCommand propertyCommand = new PropertyCommand();
propertyCommand.setAuthorized(true);
propertyCommand.setSecurityControllerId("adminController");

// Configure the new command since it was created programmatically.
getCommandConfigurer().configure(propertyCommand);

This should result in your commands being authorized based on user role and if you configured the postProcessorActionsToRun to visibleTracksAuthorized as above your unauthorized commands will not be visible either.

Hope this helps.