Je sais que cela semble être une nécessité étrange, mais lorsque le client veut, cela signifie que nous ne sommes laissés sans autre choix. Je travaille sur une application Web (e-commerce) et je dois enregistrer un nouveau client jusqu'à présent tout fonctionne parfaitement. Cependant, il existe une exigence avec les cas suivants
Étant donné que ces cas d'utilisation ne s'appliquent pas à certaines catégories, mais à une application Web totale, je ne suis pas sûr de la meilleure façon de la réaliser. Peu d'options à mon esprit
Handlerinterceptor qui vérifiera le rôle de client avant d'exécuter la demande réelle.
Mais pas sûr si je pense dans la bonne direction et comment nous devrions appliquer exactement l'accès à un tel type de clients.Sait que nous devons arrêter un tel client de
- Mettez à jour son profil
- Mettez à jour le mot de passe.
- toute autre mise à jour dans son profil
- ne permet pas au client de vérifier
- Les prix réalisés réels ne doivent pas être visibles
3 Réponses :
J'aime expression de Spring-Security Sans contrôle de l'accès pour annotant les méthodes de contrôleur avec des rôles autorisés, mais vous pouvez utiliser des intercepteurs d'URL, si vos actions sont facilement séparables par URL et / ou Verbe HTTP. Soit une solution devrait les empêcher d'effectuer des actions qu'ils ne devraient pas.
Ensuite, vous pouvez également limiter les données et / ou les liens que l'utilisateur peut voir simplement en spécifiant une vue différente si elles manquent d'un certain rôle (ou en utilisant le Security de ressort Autoriser la balise dans la même vue).
Merci pour l'entrée .... Je sais à propos de Autoriser tag.. mais je dois montrer des liens / section à tous les clients que seuls les clients avec un accès en lecture seule peuvent lire.
J'irais créer de nouveaux rôles et utiliser Contrôle d'accès à l'expression de Spring-Security comme suggéré par @ peter-g.
Si votre commerce électronique est une application Web traditionnelle (pages rendues de serveur), l'URL de filtrage n'est pas la meilleure approche. Dans ce cas, je combinerais:
@peuthorize annotations placées dans un appel d'inscription à la bean sera utile. Si vous invoquez myservice.methoda () et cette méthode invoque une méthode annotée this.methodb () (ceci étant myservice () ), le Les annotations de sécurité ne fonctionneront pas. Ils ne feront que travailler sur le premier appel à sur myservice (dans ce cas placé sur méthodata () ). Cela sert de pare-feu de sécurité à votre logique commerciale.
- LIEN / Filtrage de données à la page Rendu basé sur des rôles. Sur votre JSP, filtrez le contenu et les liens (qui sont en réalité des actions) qui ne correspondent pas aux rôles actifs actuels. Cela a deux objectifs. Un, pour montrer du contenu spécifique à des rôles spécifiques. Deuxièmement, la première barrière de sécurité permet d'éviter un utilisateur d'accéder à votre logique professionnelle. Vous ne leur montrez même pas qu'une action spécifique est disponible pour eux.
Compte tenu de cela, l'utilisateur ne pourra jamais cliquer sur le bouton / le lien pour accéder à la ressource protégée. Si vous manquez, les annotations de la couche de service agiront en tant que pare-feu final protégeant l'exécution d'actions privilégiées. De la même manière que vous filtrez hypermedia / données, vous pouvez filtrer les prix.
Si votre backend est une API Web, vous pouvez utiliser un filtrage URL avec des annotations ou une configuration XML / Java et filtrer la sortie à l'aide de Vues Jackson (si vous utilisez JSON) ou XSLT si vous utilisez XML. Il permet un contrôle grain fini et une mise en œuvre plus cohérente de la sécurité.
La meilleure approche consiste à utiliser un mécanisme de contrôle d'accès simple basé sur un rôle ( RBAC ). Ceci est bien soutenu par la sécurité du printemps et facile à utiliser.
Vous devez créer un nouveau rôle (E.G. "FULL_Access") et attribuez-le aux utilisateurs corrects en fonction de leur adresse e-mail. Le rôle devrait couvrir les utilisateurs avec un accès complet, pas ceux avec des droits en lecture seule que votre question suggérée.
Vous déterminez généralement les rôles de l'utilisateur actuel dans votre implémentation de votre mise en œuvre de userDétailsService. Vous pouvez utiliser org.springframework.security.core.Authority.SimpleGantedAuthority comme mise en œuvre de votre bénéficiaire (dans votre contexte accordéAuthority est la même chose que le rôle). Les bénéficiaires subventionnés de votre utilisateurDétailsService sont stockés à l'intérieur de l'objet d'authentification de votre utilisateur et sont disponibles dans la validité de la session de l'utilisateur.
Cette approche vous permet également de modifier facilement l'utilisateur à partir de mode en lecture seule (par exemple Après l'approbation de l'enregistrement), en ajoutant le rôle «FULL_ACCESS» lors de la prochaine connexion de l'utilisateur après l'approbation.
Une fois que vous avez rempli vos autorisateurs, vous pouvez utiliser des moyens d'autorisation déclaratifs et programmatiques. Pour une autorisation programmatique (autorisation rendue directement dans votre code), utilisez par exemple: pour autorisation déclarative (autorisation déclarée dans vos fichiers de configuration ou comme annotations à coder), vous pouvez utiliser sécurisation des appels de méthode avec des aspects ou des annotations < / a>. Vous pouvez également utiliser des URL prétendamment sécurisées en utilisant Contrôle d'accès à l'expression , mais les deux approches précédentes sont plus appropriées. La même URL peut être accessible par les utilisateurs ayant des droits d'accès complets et en lecture seule, ce qui rend cette technique difficile à utiliser pour votre cas d'utilisation. Spring Security fournit également un ensemble de Aurhorization JSP Tags qui pourrait vous aider à rendre votre assurance-emploi correctement pour Les différents types d'utilisateurs. Vous pouvez utiliser une combinaison de techniques ci-dessus pour appliquer les 5 points de logique des 5 entreprises mentionnés dans votre question.