Implémentation du contrôle d'accès dans des beans de données

Si un bean de données doit être protégé, il peut être directement ou indirectement protégé par des stratégies de contrôle d'accès. Si un bean de données est directement protégé, il existe une stratégie de contrôle d'accès qui s'applique à ce bean de données particulier. Si un bean de données est indirectement protégé, il délègue la protection à un autre bean de données, pour lequel une stratégie de contrôle d'accès existe.

Pourquoi et quand exécuter cette tâche

Pour déterminer si un bean de données doit être protégé, considérez ce qui suit :

Les informations contenues dans les informations relatives aux beans de données nécessitent-elles une protection ? Par exemple, ces informations sont-elles privées ? Si ce n'est pas le cas, la protection directe par le contrôle d'accès n'est pas nécessaire. Si c'est le cas, vous devez implémenter le contrôle d'accès pour le bean de données.
L'affichage instancie-t-il le bean de données en utilisant des informations provenant d'un paramètre d'entrée ? Dans ce cas, puisque vous n'êtes pas certain que le contrôle d'accès a déjà déterminé si l'utilisateur est autorisé à accéder à ces informations, vous devez protéger le nouveau bean de données.
Les beans de données sont instanciés par des affichages. L'affichage instancie-t-il le bean de données à l'aide de l'userID et du storeID à partir du contexte de commande Si oui et si le contrôle d'accès a déjà déterminé que l'accès est autorisé, la protection directe de ce bear de données ne serait pas nécessaire. Si ce n'est pas le cas, implémentez le contrôle d'accès pour le bean de données.

Si vous créez un nouveau bean de données qui doit être directement protégé par une stratégie de contrôle d'accès, le bean de données doit effectuer les opérations suivantes :

Procédure

Mettez en œuvre l'interface com.ibm.commerce.security.Protectable : En tant que tel, le bean doit fournir une implémentation des méthodes getOwner() et fulfills(Long member, String relationship). Lorsqu'un bean de données implémente l'interface Protectable, le gestionnaire de beans de données appelle la méthode isAllowed pour déterminer si l'utilisateur dispose des privilèges de contrôle d'accès appropriés, en fonction des stratégies de contrôle d'accès existantes. La méthode isAllowed est décrite par l'extrait de code suivant :
```
isAllowed(Context, "Display", protectable_databean);
```
où protectable_databean est le bean de données à protéger.
Si les ressources avec lesquelles le bean interagit sont regroupées par un attribut autre que le nom de classe Java de la ressource, le bean doit implémenter l'interface com.ibm.commerce.grouping.Groupable.
Mettez en œuvre l'interface com.ibm.commerce.security.Delegator : Cette interface est décrite par l'extrait de code suivant :
```
Interface Delegator {
        Protectable getDelegate();
}
```
Remarque : Afin d'être directement protégée, la méthode getDelegate doit renvoyer le bean de données lui-même (c'est-à-dire, que le bean de données délègue à lui-même pour le contrôle d'accès).

Résultats

La distinction entre les beans de données qui doivent être protégés directement et ceux qui doivent être protégés indirectement est similaire à la distinction entre les ressources primaires et les ressources dépendantes. Si l'objet de bean de données peut exister seul, il doit être protégé directement. Si l'existence d'un bean de données dépend de l'existence d'un autre bean de données, la protection doit être déléguée à l'autre bean de données.

Le bean de données Order constitue un exemple de bean de données à protéger directement. Le bean de données OrderItem constitue un exemple de bean de données à protéger indirectement.

Si vous créez un nouveau bean de données qui doit être indirectement protégé par une stratégie de contrôle d'accès, le bean de données doit implémenter l'interface com.ibm.commerce.security.Delegator. Cette interface est décrite par l'extrait de code suivant :


Interface Delegator {
        Protectable getDelegate();
}

Remarque : Le haricot de données retourné par getDelegate doit implémenter l'interface Protectable.

Si un bean de données n'implémente pas l'interface Delegator, il est rempli sans la protection des stratégies de contrôle d'accès.