Projet

Général

Profil

Actions

Bug #15217

fermé

Erreur 403 quand on supprime définitivement des utilisateurs

Bug #15217: Erreur 403 quand on supprime définitivement des utilisateurs

Ajouté par David Lesimple il y a 5 mois. Mis à jour il y a environ un mois.

Statut:
Closed
Priorité:
Normal
Assigné à:
Catégorie:
Administration
Début:
11/03/2026
Echéance:
% réalisé:

0%

Temps estimé:
Navigateur:
Tous
Votre version de Silverpeas:
6.4
Système d'exploitation:
Votre base de données:
Toutes
Livraison en TEST:
Livraison en PROD:

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 5 mois Actions #1

  • 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 5 mois · Edité Actions #2

Miguel Moquillon a écrit (#note-1):

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.

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 4 mois Actions #3

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 3 mois · Edité Actions #4

clipboard-202605191457-jgwrf.png

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 environ 2 mois Actions #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)

Mis à jour par David Lesimple il y a environ 2 mois Actions #6

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 environ 2 mois Actions #7

j'ai mis à jour le bon scénario..
https://tracker.silverpeas.org/issues/15217#note-4

Mis à jour par Miguel Moquillon il y a environ un mois Actions #8

  • Statut changé de Feedback à Qualified

Ok, je reproduis le bug mais aussi avec la page des utilisateurs supprimés et voulant supprimer définitivement tous ceux sélectionnés dans la première pas

Mis à jour par Miguel Moquillon il y a environ un mois Actions #9

  • Statut changé de Qualified à In progress...

Mis à jour par Miguel Moquillon il y a environ un mois Actions #10

  • Statut changé de In progress... à Closed

Corrigée directement dans la branche 6.4.x et reportée dans les branches master et master-jee

Actions

Formats disponibles : PDF Atom