Implémentation du contrôle d'accès
Cette rubrique décrit comment implémenter le contrôle d'accès dans le code personnalisé. En général, les beans métier et les beans de données sont des ressources que vous voudrez peut-être protéger. Toutefois, tous les beans métiers et les beans de données ne devraient pas être protégés. Dans l'application HCL Commerce existante, les ressources nécessitant une protection implémentent déjà l'interface Protectable. Généralement, la question des ressources à protéger est soulevée lors de la création de nouveaux beans métier et de données. Le choix des ressources à protéger dépend de votre application.
Pourquoi et quand exécuter cette tâche
Si une commande renvoie un bean d'entreprise dans la méthode getResources, le bean d'entreprise doit être protégé car le gestionnaire de stratégie de contrôle d'accès appellera la méthode getOwner sur le bean métier. La méthode fulfills sera également appelée si une relation est spécifiée dans la stratégie de contrôle d'accès correspondante au niveau des ressources.
Si vous deviez implémenter l'interface Protectable (et donc protéger la ressource) pour tous vos propres beans métier et beans de données, votre application pourrait nécessiter de nombreuses stratégies. À mesure que le nombre de stratégies augmente, le rendement peut se dégrader et la gestion des politiques devient plus difficile.
Une distinction théorique est faite entre les ressources primaires et les ressources dépendantes. Une primary resource peut exister par elle-même. Une dependent resource n'existe que lorsque sa ressource primaire associée existe. Par exemple, dans le code d'application HCL Commerce prêt à l'emploi, le bean de l'entité Order est une ressource protégeable, mais le bean de l'entité OrderItem ne l'est pas. La raison est que l'existence d'un OrderItem dépend d'un Order. L'Order est la ressource principale et l'OrderItem est une ressource dépendante. Si un utilisateur doit avoir accès à une commande, il doit également avoir accès aux articles de la commande.
De même, le bean de l'entité User est une ressource protégeable, mais le bean de l'entité Address ne l'est pas. Dans ce cas, l'existence de l'adresse dépend de l'utilisateur, de sorte que tout ce qui a accès à l'utilisateur, devrait également avoir accès à l'adresse.
Les ressources primaires doivent être protégées, mais les ressources dépendantes ne nécessitent souvent pas de protection. Si un utilisateur est autorisé à accéder à une ressource principale, il est logique que, par défaut, l'utilisateur soit également autorisé à accéder à ses ressources dépendantes.