Project

General

Profile

Bug #8122

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

Added by Serghei Mihai over 8 years ago. Updated about 1 month ago.

Status:
Solution proposée
Priority:
Normal
Assignee:
Target version:
-
Start date:
27 August 2015
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

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

History

#1

Updated by Frédéric Péters (de retour le 27 mai) over 8 years ago

  • Subject changed from une page "privée" de combo devrait afficher un message quand elle est accédée en mode "public" to une page "privée" de combo devrait pouvoir afficher un message d'erreur d'accès
  • Description updated (diff)
#2

Updated by Frédéric Péters (de retour le 27 mai) over 8 years ago

  • Project changed from Publik to Combo
#3

Updated by Frédéric Péters (de retour le 27 mai) over 8 years ago

  • Subject changed from une page "privée" de combo devrait pouvoir afficher un message d'erreur d'accès to une page "privée" devrait pouvoir afficher un message d'erreur d'accès
#4

Updated by Frédéric Péters (de retour le 27 mai) 6 months ago

  • Tags set to tri2023, accessible
  • Planning set to No
#5

Updated by Robot Gitea 4 months ago

  • Status changed from Nouveau to En cours
  • Assignee set to Yann Weber

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

#6

Updated by Robot Gitea 4 months ago

  • Status changed from En cours to Solution proposée
#7

Updated by Robot Gitea 4 months ago

  • Status changed from Solution proposée to En cours

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

#9

Updated by Robot Gitea 4 months ago

  • Status changed from En cours to Solution proposée
#10

Updated by Benjamin Dauvergne 4 months ago

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

Updated by Benjamin Dauvergne 4 months ago

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

Updated by Robot Gitea 3 months ago

  • Status changed from Solution proposée to En cours

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

#13

Updated by Robot Gitea 3 months ago

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

#14

Updated by Robot Gitea 3 months ago

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

#15

Updated by Yann Weber 3 months ago

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

Updated by Valentin Deniaud 3 months ago

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

Updated by Yann Weber 3 months ago

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

Updated by Benjamin Dauvergne 3 months ago

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

Updated by Yann Weber 3 months ago

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() )

#20

Updated by Robot Gitea about 1 month ago

Benjamin Dauvergne (bdauvergne) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#21

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée

Yann Weber (yweber) a demandé une relecture de Benjamin Dauvergne (bdauvergne) sur une pull request sur Gitea concernant cette demande :

Also available in: Atom PDF