Implémentation du contrôle d'accès pour les commandes de contrôleur.

Pour les stratégies de contrôle d'accès au niveau de la commande pour les commandes de contrôleur, le nom d'interface de la commande est spécifié comme ressource. Pour qu'une ressource soit protégée, elle doit implémenter l'interface Protectable. Selon le modèle de programmation HCL Commerce, c'est possible en étendant l'interface de la commande à partir de l'interface com.ibm.commerce.command.ControllerCommand et l'implémentation de la commande à partir de com.ibm.commerce.command.ControllerCommandImpl. L'interface ControllerCommand étend l'interface com.ibm.commerce.command.AccCommand, qui étend Protectable à son tour. L'interface AccCommand est l'interface minimale qu'une commande doit implémenter pour être protégée par un contrôle d'accès au niveau de la commande.

Si la commande accède aux ressources à protéger, créez une variable d'instance privée de type AccessVector pour contenir les ressources. Remplacez ensuite la méthode getResources puisque l'implémentation par défaut de cette méthode renvoie une valeur NULL et, par conséquent, aucune vérification des ressources ne se produit.

Dans la nouvelle méthode getResources, vous devez renvoyer un tableau de ressources ou de paires ressource-action sur lesquelles la commande peut agir. Lorsqu'une action n'est pas explicitement spécifiée, l'action concerne par défaut le nom de l'interface de la commande exécutée.

L'action doit être spécifiée uniquement lorsqu'une commande effectue à la fois une opération de lecture et d'écriture sur différentes instances d'une même classe de ressources. Par exemple, dans la commande OrderCopy, il peut lire à partir d'une commande source et écrire vers une commande cible. Dans ce cas, une différenciation doit être faite entre les deux actions. C'est possible en spécifiant l'action "Read" pour la commande source et l'action "Write" pour la commande cible. Lorsque le cadre de contrôle d'accès détecte ces actions, il leur ajoute automatiquement le nom d'interface de la commande au début avant de rechercher les stratégies applicables. Dans ce cas, les actions qui seront finalement utilisées dans les stratégies sont les actions "com.ibm.commerce.order.commands.OrderCopyCmd-Read" et "com.ibm.commerce.order.commands.OrderCopyCmd-Write".

En outre, il est recommandé que la méthode détermine si elle doit instancier la ressource ou si elle peut utiliser la variable d'instance existante contenant la référence à la ressource. Vérifier si l'objet de ressource existe déjà peut aider à améliorer les performances du système. Vous pouvez ensuite utiliser la même variable d'instance, si nécessaire, dans la méthodeperformExecute de la nouvelle commande de contrôleur.

Pour déterminer si vous devez remplacer la méthode getResources, considérez ce qui suit :

• Si vous dérivez la ressource en fonction d'une source d'informations prédéfinie, telle que le contexte de la commande, vous n'aurez pas besoin de remplacer la méthode getResources. Par exemple, la commande HCL Commerce UserRegistrationUpdate déduit l'ID de l'utilisateur du contexte de commande. Dans ce cas, l'utilisateur est déjà autorisé à agir sur ses propres informations d'enregistrement, de sorte que la méthode getResources n'a pas besoin d'être remplacé.
• Si votre commande spécifie arbitrairement une nouvelle ressource (et que cette ressource est de nature privée), vous devez remplacer la méthode getResources. À titre d'exemple, la commande HCL Commerce OrderItemUpdate prend un ID de commande comme paramètre d'entrée. Dans ce cas, lorsque la ressource de commande est instanciée, vous ne savez pas si l'utilisateur a le droit d'agir sur cette ressource particulière. Dans ce cas, la méthode getResources est remplacée.

Voici un exemple de la méthode getResources :

private AccessVector resources = null;

public AccessVector getResources() throws ECException { 

 if (resources == null) {
  OrderAccessBean orderAB = new OrderAccessBean(); 
  orderAB.setInitKey_orderId(getOrderId().toString()); 
  resources = new AccessVector(orderAB); 
  }
 return resources;
}

À titre d'exemple, considérez la commande OrderItemUpdate. La méthode getResources de cette commande renvoie un ou plusieurs objets Order (qui sont protégeables) lorsqu'elle met à jour les commandes existantes. Comme l'action n'est pas spécifiée, l'action est définie par défaut sur l'interface de la commande OrderItemUpdate.

Plusieurs ressources peuvent être retournées par la méthode getResources. Lorsque cela se produit, une stratégie qui donne à l'utilisateur l'accès à toutes les ressources spécifiées doit être trouvée si l'action doit être effectuée. Si un utilisateur a eu accès à deux ressources sur trois, l'action peut ne pas se poursuivre (trois sur trois sont nécessaires).

Si vous devez effectuer des vérifications ou des résolutions de paramètres supplémentaires dans la commande de contrôleur, vous pouvez utiliser la méthode validateParameters(). L'utilisation de cette méthode est facultative.

Vérification supplémentaire du niveau des ressources

Il n'est pas toujours possible de déterminer toutes les ressources qui doivent être protégées, au moment où la méthode getResources de la commande du contrôleur est appelée.

Si nécessaire, une instruction de tâches peut également implémenter une méthode getResources pour renvoyer une liste de ressources, sur laquelle l'instruction peut agir.

Une autre façon d'invoquer la vérification au niveau des ressources consiste à effectuer des appels directs au gestionnaire de stratégies de contrôle d'accès, à l'aide de la méthode checkIsAllowed(Object resource, String action). Cette méthode est disponible pour toute classe qui s'étend à partir de la classe com.ibm.commerce.command.AbstractECTargetableCommand. Par exemple, les classes suivantes s'étendent à partir de la classe AbstractECTargetableCommand :

• com.ibm.commerce.command.ControllerCommandImpl
• com.ibm.commerce.command.DataBeanCommandImpl

La méthode checkIsAllowed est également disponible pour les classes qui prolongent la classe com.ibm.commerce.command.AbstractECCommand. Par exemple, la classe suivante s'étend à partir de la classe AbstractECCommand :

• com.ibm.commerce.command.TaskCommandImpl

Ce qui suit montre la signature de la méthode checkIsAllowed :

void checkIsAllowed(Object resource, String action) 
 throws ECException

Cette méthode renvoie l'exception ECApplicationException si l'utilisateur en cours n'est pas autorisé à exécuter l'action indiquée sur la ressource spécifiée. Si l'accès est accordé, la méthode retourne simplement.

Contrôle d'accès pour les commandes "créer"

Étant donné que la méthode getResources est appelée avant la méthode performExecute dans une commande, une approche différente doit être adoptée pour le contrôle d'accès pour les ressources qui ne sont pas encore créées. Par exemple, si vous avez un WidgetAddCmd, la méthode getResources ne peut pas renvoyer la ressource qui est sur le point d'être créée. Dans ce cas, la méthode getResources doit retourner le conteneur de la nouvelle ressource. Par exemple, si une commande est créée, cela se fait dans la ressource du magasin et un nouvel utilisateur est créé au sein d'une ressource d'organisation.

Implémentations par défaut pour le contrôle d'accès au niveau de la commande

Pour le contrôle d'accès au niveau de la commande, l'implémentation par défaut de la méthode getOwner() renvoie le memberId du propriétaire du magasin, si le storeId est spécifié. Si le storeId n'est pas spécifié, le membreId de l'organisation racine est renvoyé (memberId = -2001).

L'implémentation par défaut de la méthode getResources() renvoie null.

L'implémentation par défaut de validateParameters() ne renvoie rien.