Bug #15217
ouvert
Erreur 403 quand on supprime définitivement des utilisateurs
0%
Description
Erreur :
2026-03-11 09:59:24,167 SEVERE [silverpeas.web.jobdomain.servlets] (default task-26) http error 403 [/silverpeas/RjobDomainPeas/jsp/blankUsers] -> Forbidden admin access to user with id 0
Fichiers
Mis à jour par Miguel Moquillon il y a 3 mois
- Statut changé de New à Feedback
Je n'arrive pas à reproduire le problème.
Une telle erreur devrait survenir lorsque le token X-ATKN , passé dans la page Web, n'est pas renvoyé à Silverpeas. La page concernée ici est générée par la JSP deletedUsers.jsp , et le token est passé programmatiquement, en JavaScript, à la requête HTTP envoyée par la page lors de la validation du formulaire d'anonymisation des utilisateurs sélectionnés. Il faudrait ici s'assurer que ce token est bien renvoyé (et non filtré par un proxy/passerelle) et que c'est bien cette page qui est utilisée et qu'elle n'a pas été personnalisée.
Mis à jour par David Lesimple il y a 3 mois
· Edité
Miguel Moquillon a écrit (#note-1):
Je n'arrive pas à reproduire le problème.
Une telle erreur devrait survenir lorsque le tokenX-ATKN, passé dans la page Web, n'est pas renvoyé à Silverpeas. La page concernée ici est générée par la JSPdeletedUsers.jsp, et le token est passé programmatiquement, en JavaScript, à la requête HTTP envoyée par la page lors de la validation du formulaire d'anonymisation des utilisateurs sélectionnés. Il faudrait ici s'assurer que ce token est bien renvoyé (et non filtré par un proxy/passerelle) et que c'est bien cette page qui est utilisée et qu'elle n'a pas été personnalisée.
J'ai le token X-STKN mais pas X-ATKN à l'appel de la liste des utilisateurs supprimés:
../displayDeletedUsers?X-STKN=OGEyYjE4YWUtMGYwNi00OWEwLTg0ZGItMWYwZjZlMWRmZDZj
Parfois ça passe, parfois non...
Mis à jour par Miguel Moquillon il y a 3 mois
Le token X-ATKN est passé directement côté serveur à la JSP à partir de laquelle la page HTML avec la liste des utilisateurs supprimés est affichée. Le token X-ATKN est alors passé comme paramètre du formulaire HTML par Javascript lors de la validation de l'application du droit à l'oubli. Cf. JSP deletedUsers.jsp , ligne 48 :
function validate() {
const formRequest = sp.formRequest("blankUsers").byPostMethod();
checkboxMonitor.prepareFormRequest(formRequest);
formRequest.addParam('X-ATKN', '${requestScope["X-ATKN"]}');
formRequest.submit();
}
Mis à jour par David Lesimple il y a environ un mois
· Edité
- Fichier clipboard-202605191457-jgwrf.png clipboard-202605191457-jgwrf.png ajouté
Pré-requis: la liste doit être paginée.
Scénario pour reproduire le problème :
- Allez sur la liste des utilisateurs supprimés
- Sélectionner une entrée de la page 1
Résultat: La suppression a bien fonctionné.
- revenir sur la liste des utilisateurs supprimés
- Sélectionner une entrée de la page 2, valider
Erreur 403.
Mis à jour par Miguel Moquillon il y a un jour
Il y a un soucis avec ton scénario. Quand on applique le droit à l'oubli à un, plusieurs, ou tous les utilisateurs de la page, paginée ou non, on revient automatiquement à la page des utilisateurs du domaine ; il n'y a pas de rafraîchissement de la page des utilisateurs définitivement supprimés (du moins dans la future version 6.4.7)
Mis à jour par David Lesimple il y a un jour
Miguel Moquillon a écrit (#note-5):
Il y a un soucis avec ton scénario. Quand on applique le droit à l'oubli à un, plusieurs, ou tous les utilisateurs de la page, paginée ou non, on revient automatiquement à la page des utilisateurs du domaine ; il n'y a pas de rafraîchissement de la page des utilisateurs définitivement supprimés (du moins dans la future version 6.4.7)
En effet, il faut revenir sur une page autre que la 1ère (2 par exemple) et supprimer des utilisateurs, c'est là que l'erreur 403 survient.
Mis à jour par David Lesimple il y a un jour
j'ai mis à jour le bon scénario..
https://tracker.silverpeas.org/issues/15217#note-4