Bug #8122
une page "privée" devrait pouvoir afficher un message d'erreur d'accès
0%
Description
Au lieu de forcer le SSO, une page devrait permettre l'affichage d'un message personnalisable.
Historique
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)
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
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 :
- URL : https://git.entrouvert.org/entrouvert/combo/pulls/218
- Titre : WIP: data: add custom error message when Page display is not allowed (#8122)
- Modifications : https://git.entrouvert.org/entrouvert/combo/pulls/218/files
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 :
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).
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).
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 :
- URL : https://git.entrouvert.org/entrouvert/combo/pulls/218
- Titre : WIP: public: change permission denied handling (#8122)
- Modifications : https://git.entrouvert.org/entrouvert/combo/pulls/218/files
Mis à jour par Robot Gitea il y a environ un mois
Yann Weber (yweber) a fermé une pull request sur Gitea concernant cette demande.
Mis à jour par Robot Gitea il y a environ un mois
Yann Weber (yweber) a ouvert une pull request sur Gitea concernant cette demande :
- URL : https://git.entrouvert.org/entrouvert/combo/pulls/234
- Titre : WIP: public: add error403 view and make publish_page use it (#8122)
- Modifications : https://git.entrouvert.org/entrouvert/combo/pulls/234/files
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 ?).
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.
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 :)
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.
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()
)