Sécuriser et empêcher l'exécution d'une servlet par un visiteur

Bonjour,

J'ai une page jsp appelée "modificationDocument.jsp" qui possède un bouton suppression avec un lien dirigeant vers une servlet pour supprimer une donnée dans ma base de donnée.

Mon bouton suppression:

Code:

---

<a href='supprimerDocument?id=233' ><button type='button' class='btn btn-default'>Supprimer</button></a>

---

Ma servlet avec la méthode doGet() prend la valeur du parametre de id transmise dans l'URL, supprime la donnée et affiche une page de résultat.

J'ai deux problèmes:

J'aimerai quel seul un utilisateur authentifié puisse pouvoir exécuter la servlet avec URL "/supprimerDocument" . Actuellement un visiteur quelconque peut taper le lien URL vers la servlet et accéder comme il le désire sans avoir de restriction.
J'ai pensé à une solution dans ma méthode doGet de chacune de mes servlets vérifier si la session a été crée si elle a été créer regarder si l'utilisateur existe dans ma base de donnée sinon rediriger vers la page d'accueil. Je ne sais pas si c'est la meilleur manière de procéder.

Mon autre problème:
Si l'utilisateur est bien authentifié, Existe t-il un moyen que l'utilisateur ne puisse exécuter "/supprimerDocument?id=233" uniquement à partir du bouton "Supprimer" dans ma page "modificationDocument.jsp".
Je ne voudrais pas que l'utilisateur authentifié puisse taper "/supprimerDocument?id=32324" dans l'URL directement.


Merci d'avance
Si vous avez des pistes ou idées je suis preneur :)

Bonsoir,


La méthode GET sert à afficher une ressource, ici tu t'en sers pour supprimer quelque chose. Ce n'est pas la bonne méthode, si tu veux bien faire les choses, tu dois envoyer une requête HTTP avec la méthode DELETE. Cela signifie qu'au niveau de ta servlet, tu dois utiliser non pas doGet(), mais doDelete().

Tu peux vérifier si l'utilisateur est authentifié à partir d'un filtre (cf: Filter). Si ton utilisateur est authentifié, tu dois vérifier dans ta base s'il a les permissions nécessaires pour supprimer ta ressource dont l'id est 233, si oui tu vas supprimer ta ressource et retourner un code 200 (ok), sinon tu dois retourner le code d'erreur 403 (non autorisé).


A+

Personnellement, j'aurais utilisé la méthode doPost pour exécuter le traitement, du coup, la requête à partir de la barre d'adresse ne fonctionnera pas.
Pour ce qui est de l'utilisateur authentifié, tout dépend du type d'authentification.
Si tu as un système basé sur JAAS, tu peux savoir si la requête est liée à un utilisateur authentifié si request.getUserPrincipal() te renvoie quelque chose.
Si c'est un système "maison", là, ça dépend de ce qui a été prévu... souvent un objet mis en session.

Citation:

---

Envoyé par Gugelhupf

Bonsoir,


La méthode GET sert à afficher une ressource, ici tu t'en sers pour supprimer quelque chose. Ce n'est pas la bonne méthode, si tu veux bien faire les choses, tu dois envoyer une requête HTTP avec la méthode DELETE.

---

Ce qui est assez difficile à atteindre sans passer par du javascript, un XmlHttpRequest et tout le toutim. De base le browser ne permet de faire que du GET ou du POST, donc pour moi du POST est suffisant, il n'implémente pas un service RESTFUL là :)

Pour répondre à la question, il faut d'abors que l'on sache comment tu gère tes utilisateurs. Si tu gére l'authentification directement au niveau de ton conteneur avec un LOGIN-FORM ou une authentification basic, tu peux simplement mettre une entrée dans ton web.xml disant que la servlet n'est accessible que par un admin

Code:

---

1 2 3 4 5 6 7 8 9 10

<security-constraint> <web-resource-collection> <web-resource-name>suppression</web-resource-name> <url-pattern>/supprimerDocument</url-pattern> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>ADMINISTRATOR</role-name> </auth-constraint> </security-constraint>

---

Sinon, comme suggéré un Filter que tu applique sur toutes les servlet. Dans tous les cas, pas besoin de dupliquer le code dans chaque servlet.

Oui, à force de faire du RESTful avec JavaScript j'en oublie les limitations de la norme des <form> HTML qui n'autorisent pas le PUT et le DELETE :)
Je ne connaissais pas ces balises, je me suis toujours demandé s'il y avait un équivalent de Spring Security avec les servlets, du coup comment gérer (setter/getter) le role-name de l'utilisateur ?

Citation:

---

Envoyé par Gugelhupf

Je ne connaissais pas ces balises, je me suis toujours demandé s'il y avait un équivalent de Spring Security avec les servlets, du coup comment gérer (setter/getter) le role-name de l'utilisateur ?

---

Pas sûr de comprendre ta question mais si tu cherches à tester le rôle d'un utilisateur authentifié, tu as la méthode isUserInRole(String role) de HttpServletRequest qui est là pour ça.

Salut OButterlin,

Je faisais référence à la classe SecurityContextHolder de Spring pour récupérer le contexte et setter/getter l'Authentication (c'est une classe qui implémente l'interface Principal de Java). Du coup je n'ai pas vu de pattern équivalent dans le standard Java.

Source: Documentation Spring pour la sécurité.

C'est vrai que ça doit être différent, ils ont un module spécifique que je sache... mais comme je ne connais pas Spring plus que ça (je l'ai utilisé 1 mois sur 1 petit projet) je ne sais pas au juste ce que ça fait...
J'utilise la pile standard JAAS, avec enrichissement de l'objet Principal pour gérer les attributs spécifiques dont on a besoin chez nous...
Plus de nombreuses subtilités pour un "auto-login" via SPNEGO et une authentification par jeton... bref... rien de standard là ;)