Projet

Général

Profil

Bug #8122

une page "privée" devrait pouvoir afficher un message d'erreur d'accès

Ajouté par Serghei Mihai il y a plus de 8 ans. Mis à jour il y a environ un mois.

Statut:
En cours
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
27 août 2015
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Au lieu de forcer le SSO, une page devrait permettre l'affichage d'un message personnalisable.

Historique

#1

Mis à jour par Frédéric Péters il y a plus de 8 ans

  • Sujet changé de une page "privée" de combo devrait afficher un message quand elle est accédée en mode "public" à une page "privée" de combo devrait pouvoir afficher un message d'erreur d'accès
  • Description mis à jour (diff)
#2

Mis à jour par Frédéric Péters il y a plus de 8 ans

  • Projet changé de Publik à Combo
#3

Mis à jour par Frédéric Péters il y a plus de 8 ans

  • Sujet changé de une page "privée" de combo devrait pouvoir afficher un message d'erreur d'accès à une page "privée" devrait pouvoir afficher un message d'erreur d'accès
#4

Mis à jour par Frédéric Péters il y a 4 mois

  • Tags mis à tri2023, accessible
  • Planning mis à Non
#5

Mis à jour par Robot Gitea il y a 2 mois

  • Statut changé de Nouveau à En cours
  • Assigné à mis à Yann Weber

Yann Weber (yweber) a ouvert une pull request sur Gitea concernant cette demande :

#6

Mis à jour par Robot Gitea il y a 2 mois

  • Statut changé de En cours à Solution proposée
#7

Mis à jour par Robot Gitea il y a environ 2 mois

  • Statut changé de Solution proposée à En cours

Valentin Deniaud (vdeniaud) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#9

Mis à jour par Robot Gitea il y a environ 2 mois

  • Statut changé de En cours à Solution proposée
#10

Mis à jour par Benjamin Dauvergne il y a environ un mois

Fred a raison dans son commentaire sur gitea:

Si j'arrive à suivre correctement, ça ne me semble pas approprié, ça voudrait dire qu'un premier accès sur le portail agent afficherait une page d'erreur, plutôt qu'envoyer l'usager se connecter.

J'ai l'impression qu'en fait tout est confus entre les différentes directions, la description un peu courte du ticket, le ticket lié toulouse qui demande une page 403 différente, mes commentaires, etc.

Il faut peut-être prendre du recul et refaire une description fonctionnelle un peu exhaustive de ce qu'on veut atteindre, avant de continuer sur le code.

J'ai lié mon ticket Toulouse, il faudrait lier l'autre ticket client qui a mené à l'ouverture de celui-ci, mais en parlant uniquement du cas Toulouse, le seul cas qui nous intéresse c'est quand l'utilisateur est connecté, si l'utilisateur n'est pas connecté il ne faut rien changer au comportement actuel. Et je pense que ça mérite une vue error403 comme on a une error404, pour faire propre et simplifier le code dans publish_page() (et définir handler403, idem, https://docs.djangoproject.com/fr/4.2/topics/http/urls/#error-handling).

#11

Mis à jour par Benjamin Dauvergne il y a environ un mois

Donc pour Toulouse le cas d'usage: une page bloqué pour un groupe précis, généralement Agent, on souhaite un message disant "vous n'êtes pas Agent, merci de vous connecter avec un compte agent".

Je peux imaginer qu'il y ait un cas d'usage pour les pages limités aux utilisateurs authentifiés, mais le fonctionnement actuel me semble suffisant dans la plupart des cas et parce que normalement l'indication du besoin d'authentification devrait se faire sur une page précédente. On ne devrait jamais avoir de page totalement fermée en premier niveau d'un site ou d'une zone du site. Et dans ce dernier cas on affiche juste pas de lien vers des pages nécessitant une authentificaton/un rôle, on oriente l'utilisateur dans le rédactionnel (exemple: zone portail famille qui indique qu'on a pas de compte famille).

#12

Mis à jour par Robot Gitea il y a environ un mois

  • Statut changé de Solution proposée à En cours

Yann Weber (yweber) a commencé à travailler sur une pull request sur Gitea concernant cette demande :

#13

Mis à jour par Robot Gitea il y a environ un mois

Yann Weber (yweber) a fermé une pull request sur Gitea concernant cette demande.

#14

Mis à jour par Robot Gitea il y a environ un mois

Yann Weber (yweber) a ouvert une pull request sur Gitea concernant cette demande :

#15

Mis à jour par Yann Weber il y a environ un mois

J'ai fais un test rapide avec l'implémentation d'une vue error403 et la définition de handler403 ( https://git.entrouvert.org/entrouvert/combo/pulls/234 ).

Mais j'avoue que je ne vois pas trop comment conserver le comportement actuel (302 vers le login quand pas connecté) et continuer à renvoyer des 403 pour les appels d'API (sinon à faire des trucs un peu tordus comme faire une différence selon l'URL appelée ?).

#16

Mis à jour par Valentin Deniaud il y a environ un mois

Yann Weber a écrit :

Mais j'avoue que je ne vois pas trop comment conserver le comportement actuel (302 vers le login quand pas connecté) et continuer à renvoyer des 403 pour les appels d'API (sinon à faire des trucs un peu tordus comme faire une différence selon l'URL appelée ?).

Dans le handler on pourrait vérifier si request.is_ajax() or request.content_type == 'application/json', moyen que ça chope tous les appels API, et dans ce cas renvoyer une 403 simple.

Sinon on pourrait lever une nouvelle exception PagePermissionDenied et remplacer le middleware de Django qui rattrape l'exception PermissionDenied par un à nous.

#17

Mis à jour par Yann Weber il y a environ un mois

Valentin Deniaud a écrit :

Dans le handler on pourrait vérifier si request.is_ajax() or request.content_type == 'application/json', moyen que ça chope tous les appels API, et dans ce cas renvoyer une 403 simple.

Malheureusement (dans les tests en tout cas) request.is_ajax() renvoie False et request.content_type vaut la chaîne vide.

Sinon on pourrait lever une nouvelle exception PagePermissionDenied et remplacer le middleware de Django qui rattrape l'exception PermissionDenied par un à nous.

Oui, c'est une des solutions que j'envisageais, d'autant que l'implémentation devrait être plus simple : le handler403 reçoit l'exception en argument :)

#18

Mis à jour par Benjamin Dauvergne il y a environ un mois

Valentin Deniaud a écrit :

Yann Weber a écrit :

Mais j'avoue que je ne vois pas trop comment conserver le comportement actuel (302 vers le login quand pas connecté) et continuer à renvoyer des 403 pour les appels d'API (sinon à faire des trucs un peu tordus comme faire une différence selon l'URL appelée ?).

J'ai l'impression que ça ne concerne que ajax_page_cell et skeleton, tout ce qui est implémenté avec DRF n'a pas ce souci (il y a une exception différente qui est utilisée bien qu'elle s'appelle PermissionDenied), on peut peut-être juste adapter ces deux vues.

#19

Mis à jour par Yann Weber il y a environ un mois

Benjamin Dauvergne a écrit :

J'ai l'impression que ça ne concerne que ajax_page_cell et skeleton, tout ce qui est implémenté avec DRF n'a pas ce souci (il y a une exception différente qui est utilisée bien qu'elle s'appelle PermissionDenied), on peut peut-être juste adapter ces deux vues.

Peut être que je comprend mal, mais j'ai l'impression que d'autres vues sont concernés et seraient à adapter.

Par exemple combo.apps.gallery.views.ImageAddView (voir https://jenkins.entrouvert.org/job/gitea/job/combo/job/wip%252F8122-error403-view/1/testReport/junit/coverage-py3-django32-codestyle.tests/test_gallery_cell/test_adding_gallery_images_False_/ )

Ou encore combo.apps.dashboard.DashboardAddTileView (qui, contrairement à la vue cité au dessus, ne permet pas d'être différencié par la solution proposée par Valentin à base de request.is_ajax() )

Formats disponibles : Atom PDF