J'essaie de créer une application WebApplication, qui utilisera une extrémité avant JS et d'invoquer le ressort WS dans le backend. Disons que ceci est un site de shopping type de site Web. Donc, je pourrais avoir des services comme Quelle est la meilleure pratique en matière de gestion de session avec Webservices? Je suppose que la meilleure pratique est vraiment de garder le service apatride, mais comment puis-je autoriser les utilisateurs si je n'ai pas d'espoir Webervices?
Est-ce une bonne pratique d'utiliser un conteneur de servlet juste pour effectuer une gestion de la session, puis disposer de différents contrôleurs agissant en tant que mandatation desservices?
Je joins une image pour vous faire comprendre le contexte mieux.
utérus inventaireservice shippingservice et ainsi de suite. La seule chose qui a besoin de session est le panier d'achat de l'utilisateur. Maintenant, juste pour ce panier, il est logique d'utiliser un conteneur de servlet pour la gestion de la session? Ou, devrais-je avoir Cartservice qui persiste les informations de session à la base de données?
3 Réponses :
Comment puis-je autoriser les utilisateurs si j'ai des webservices apatrides?
Si votre application utilise WS externe, une approche plutôt courante est décrite Ici .
Si tous les WS font partie de votre livraison, vous pouvez sûrement utiliser Spring-Security .
Une approche très courante consiste également à avoir un serveur HTTP (Apache) en tant que proxy avec quelque chose comme LDAP pour les deux, l'authentification et l'autorisation.
Est-ce une bonne pratique d'utiliser un conteneur de servlet juste pour effectuer une gestion de la session, puis disposer de différents contrôleurs agissant en tant que mandatation desservices?
Je penserais que ce n'est pas le cas. Comme il a également discuté ici , vous ne pouvez bénéficier que de conserver Vos services Web apatrides et si vous avez besoin de maintenir l'état entre les demandes, utilisez des cookies.
Si l'état (panier) devrait survivre à la déconnexion, quelque chose comme Cartservice sonne comme une bonne idée.
Sur votre point 3 - voulez-vous dire que je devrais utiliser l'authentification de base? Si son serveur HTTP, comment vais-je stocker des informations spécifiques à la session?
Nous utilisons actuellement l'authentification de base (donc cela fonctionne) mais je ne l'appellerais pas une meilleure pratique . Quoi qu'il en soit, Apache peut faire une authentification de formulaire et gérer des sessions: check Ce .
OK, je suppose que cela nécessitera que les noms d'utilisateur soient au dossier pour s'authentifier.
Peut-être que je lis cela mal mais laissant les sessions de poignée de conteneur de servlet pendant que les services Web sont apatrides est une bonne pratique.
Il pourrait y avoir un malentendu. - STATUS STATUS est en effet une bonne pratique - ayant un conteneur de servlet supplémentaire avec des contrôleurs comme proxies pour les services Web réels, ne me semble pas une bonne pratique.
@MilosGregor OK. Si le service Web est apatrice, comment savoir qu'une demande AJAX est autorisée? Disons que mon service est censé être consulté de deux applications différentes et seuls certains types d'utilisateurs de ces deux applications différentes sont autorisés à accéder. Comment savoir que la demande Ajax provient de l'utilisateur1 de WebApp1, autorisé? Et pas de l'utilisateur2 de WebApp2, qui n'est pas autorisé à accéder au service?
@Jay: S'il vous plaît, voyez ma nouvelle réponse.
Vous pouvez faire référence au Spring-WS Security
vérifier ici , pour Un exemple qui utilise WS-Security dans une application de démarrage à ressort. Plus précisément, voir WebServiceserverconfig.
ok ce lien a été utile. Mais de ce code ici - github.com/gregTurn/Learning-spring-ws/blob/security/... Je n'ai pas pu dire pourquoi une DispatcherVlet doit être mentionnée dans le cadre de la configuration. Cela signifie-t-il qu'un servlet de répartiteur gérera toutes les demandes de requête et nous devons spécifier le chemin de signification de ce site Web dans ce rappel?
Désolé, je ne suis pas un expert de Springws, si vous voulez me donner votre courrier, je vous enverrai un très bon projet de projet développé par moi-même pour un test d'emploi, avec une interface de démarrage et de swing
Eh bien, je suppose que vous pouvez utiliser une sorte de clé d'accès client dans l'en-tête de requête HTTP; Je veux dire: à partir du navigateur (après la tentative de connexion), un code d'accès client est transmis dans une en-tête HTTP personnalisée; Sur le côté serveur dans le conteneur de servlet, vous pouvez obtenir un jeton d'accès au client et vérifier s'il s'agit du jeton valide; Ensuite, vous l'utilisez pour invoquer des services Web
Donc, un simple servlet / filtre agit en tant qu'autorisateur pour tous les services Web?
Oui I0D Utilisez définitivement un servlet unique ou un filtre
Si je vais utiliser un servlet / filtre, il aurait un accès à la session, n'est-ce pas? Et s'il a accès à la session et que vous pouvez vérifier si l'utilisateur est qualifié pour accéder au service Web, je n'aurais pas besoin d'une sorte de sécurité chez My WS? Est-ce (à l'aide d'un servlet en tant que porte de sécurité) la meilleure pratique pour sécuriser vos services Web à partir de demandes d'Ajax?
Nope ... tu ne voudrais pas; Vous devez accéder à la demande et obtenir l'en-tête HTTP à la suite de la touche d'accès client. Quelque chose comme demande.Getheader ("Cust-Key"); et ensuite vérifier si cette clé est valide ou moins (selon certaines règles bien définies). Cela signifie que le navigateur doit transmettre cet en-tête HTTP dans chaque appel
@BeloimMediata Avez-vous des liens avec un didacticiel qui implémente un tel concept de clé d'accès?
Je suppose que la meilleure approche que vous pouvez utiliser est l'OAuth 2.0; Ici, peu de liens que vous pouvez voir: 1) oauth.net/2 2) EN.Wikipedia.org/wiki/oauth 3) AARONPARICKI.COM/Articles/2012/07/29/1/OAUTH2-SIMPLIFIÉ 4) développeurs.google.com/entity/protocols/oauthe2
@Angeloimmediata Voici la situation, j'ai dit, myApp.com/testapp1 et myapp.com/testapp2 . Deux applications différentes qui auraient différents ensembles d'utilisateurs. Et certains utilisateurs d'APP1 peuvent accéder à mon service Web et que certains utilisateurs d'APP2 ne peuvent pas. Dans les deux cas, ce que vous suggérez, c'est que je ne devrais pas avoir de protection contre WS, mais que l'APP1 et l'APP2 autorisent-ils les utilisateurs et effectuer des appels internes (du côté serveur d'APP1 et de l'APP2) à WS?
Nan; Je dis que vous pouvez utiliser cette approche pour générer un code client; puis transmettez ce code au WS aussi et vérifiez si le code est valide ou non