Incidences du contrôle d'accès lorsqu'une commande de contrôleur est étendue

Effet sur la méthode getResources

Si vous étendez une commande de contrôleur existante, ce qui signifie que la logique existante de la commande sera exécutée avec votre nouvelle logique personnalisée, votre nouvelle commande sera une sous-classe de la commande existante. La méthode performExecute de la nouvelle implémentation appelle la méthode performExecute de la superclasse. Si votre nouvelle commande n'accède pas à de nouvelles ressources nécessitant une protection, vous n'avez pas à écraser la méthode getResources. Toutefois, si de nouvelles ressources protégeables sont accessibles, la nouvelle commande doit implémenter sa propre méthode getResources et, dans cette méthode, faire appel à la méthode getResources de la superclasse avant d'implémenter votre propre logique getResources.

Les résultats de la méthode getResources de la superclasse doivent être stockés dans une variable d'instance privée de type AccessVector. Les résultats de la méthode getResources locale doivent ensuite être ajoutés à la fin de ce vecteur. Par exemple, la nouvelle classe d'implémentation contiendrait du code similaire au pseudo-code suivant :

private AccessVector resources = null;

public AccessVector getResources() throws ECException {
 // First, get the resources from the original implementation
 resources = super.getResources();

 // Now, append the new resources

 ////////////////////////////////////////
 // Logic for getting new resources //
 // and appending to the vector.  //
 /////////////////////////////////////////

 return resources;
}

Si vous n'étendez pas la logique d'une commande de contrôleur existante, mais que vous remplacez la logique complètement, vous ne ferez pas appel à la méthode super.performExecute dans votre nouvelle implémentation. Vous n'aurez alors pas besoin de faire appel à la méthode super.getResources à partir de votre propre implémentation. A la place, il suffit d'implémenter votre propre méthode getResources, selon le cas.

Effet sur les stratégies de contrôle d'accès au niveau de la commande

Les stratégies au niveau de la commande des commandes de contrôleur consistent en l'action "Execute" opérant sur la ressource de commande. La ressource de commande est spécifiée par son nom d'interface. Lorsque vous étendez une commande existante, la commande implémente toujours l'interface d'origine et, par conséquent, la stratégie au niveau de la commande existante est suffisante pour maintenir le précédent contrôle d'accès au niveau de la commande. Par conséquent, aucun changement n'est nécessaire.

Effet sur les stratégies de contrôle d'accès au niveau de la ressource

Si vous avez créé une nouvelle implémentation d'une commande existante et associé cette implémentation à l'interface de cette commande existante, il n'y a pas de modifications requises dans les stratégies de contrôle d'accès au niveau de la ressource.

Si vous créez plutôt une nouvelle classe d'implémentation qui étend une implémentation existante et que, dans cette classe, vous faites appel à la méthode super.performExecute, et que vous implémentez également une nouvelle interface, des modifications sont nécessaires dans les stratégies de contrôle d'accès au niveau de la ressource.

Dans le dernier cas, si la nouvelle commande implémente la méthode getResources ou hérite d'une implémentation non triviale de la méthode getResources à partir de la commande de base, des modifications des stratégies au niveau de la ressource sont nécessaires. En règle générale, les stratégies au niveau de la ressource consistent en l'action de commande opérant sur la ressource d'objet métier. Etant donné que l'action n'est qu'une représentation en chaînes de l'interface de la commande, la nouvelle commande doit généralement être ajoutée aux groupes d'actions de la commande de base. Toutefois, si la nouvelle commande écrase l'implémentation de base de la méthode getResources en renvoyant simplement zéro, aucune vérification de contrôle d'accès ne sera effectuée pour cette nouvelle commande. Soyez conscient qu'en l'absence de précautions, cela pourrait potentiellement entraîner l'ouverture de la nouvelle commande aux utilisateurs malveillants.

Lorsque vous modifiez les stratégies de contrôle d'accès au niveau de la ressource, les étapes de niveau élevé sont les suivantes :

1. Recherchez le fichier defaultAccessControlPolicies.xml qui se trouve dans le répertoire suivant :
   • WCDE_installdir\Commerce\xml\policies\xml
2. Faites une copie de ce fichier. A titre d'exemple, nommez le fichier myDefaultAccessControlPolicies.xml.
3. Dans ce nouveau fichier, vous devez définir la nouvelle interface comme une nouvelle action. Par exemple, vous ajoutez les éléments suivants :

   
   <Action Name="yourNewInterface"
            CommandName="yourNewInterface">
   </Action>
   

   où yourNewInterface est le nom de la nouvelle interface.

4. Ensuite, vous devez parcourir le fichier pour localiser tous les groupes d'actions auxquels l'action d'origine appartenait, puis ajouter votre nouvelle action.
5. Si la nouvelle commande fonctionne sur des ressources qui n'étaient pas spécifiées auparavant par la commande de base, le groupe de ressources des stratégies de contrôle d'accès correspondantes doit également être modifié pour tenir compte des nouvelles ressources.
6. Une fois que vous avez terminé vos modifications du fichier XML, vous pouvez supprimer les sections que vous n'avez pas modifiées. Assurez-vous de conserver le texte avant la balise <Policies>.

   Par exemple, une instruction appelée MyOrderItemAddCmd qui prolonge une instruction existante appelée OrderItemAddCmd est ajoutée. Etant donné qu'OrderItemAddCmdImpl implémente getResources(), la nouvelle instruction doit être définie comme une action, puis ajoutée aux groupes d'actions auxquels OrderItemAdd appartient :

   
   <?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
   <!DOCTYPE Policies SYSTEM "../dtd/accesscontrolpolicies.dtd">
   <Policies>
   <Action Name="com.xyz.MyOrderItemAddCmd"
   CommandName="com.xyz.MyOrderItemAddCmd">
   </Action>
   
   <ActionGroup Name="OrderCreateCommands" OwnerID="RootOrganization">
   <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
   </ActionGroup>
   
   <ActionGroup Name="OrderWriteCommands" OwnerID="RootOrganization"> 
   <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
   </ActionGroup>
   
   <ActionGroup Name="InterestItemReadCommands" OwnerID="RootOrganization">
   <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
   </ActionGroup>
   </Policies>
   

7. Chargez les nouvelles informations de stratégie dans la base de données.