|
|
||
| Date de création : | mai 2003 | |
| Dernière modification : | 22 mai 2003 | |
| Diffusion : | internet | |
Lors d'une mauvaise authentification sur une application web CAS-ifiée (absence de session, absence de ticket, non validation d'un ticket, ...), le navigateur web de l'utilisateur est renvoyé vers le serveur CAS à l'aide d'une redirection HTTP. La requête vers le serveur CAS est alors effectuée avec la méthode GET, et le navigateur web est ensuite redirigé par le serveur CAS vers l'application, toujours avec la méthode GET.
Lors de ces redirections, si la requête d'origine avait été effectuée avec la méthode POST, les paramètres CGI passés en POST sont perdus.
Une longue discussion (Vincent, Julien & Pascal) a permis d'envisager les différentes solutions possibles pour prendre en compte ce problème. Il est techniquement possible de conserver les paramètres CGI passés en POST à la requête originelle :
en changeant les redirections par des formulaires auto-chargeants
en introduisant quelques paramètres supplémentaires dans les
requêtes vers le serveur CAS
en modifiant le serveur CAS
Ce schéma de fonctionnement, évoqué par Vincent en Novembre
dernier à Valenciennes et déjà été implémenté par
Pascal lors d'un développement précédent, provoque hélas
un avertissement des clients lors du passage de HTTP (sur l'application cliente) à HTTPS
(serveur CAS). Pour cette raison, le schéma est rejeté.
Il est alors considéré comme impossible de propager les paramètres CGI POST avec les navigateurs web actuels.
Il est alors décidé de traiter au mieux les requêtes POST qui devraient être redirigées.
Si une requête POST est considérée comme non authentifiée par mod_cas, un message est affiché prévenant l'utilisateur de l'erreur (absence de session mod_cas, mauvais identificateur de session mod_cas ou session mod_cas périmée) et invite l'utilisateur à cliquer sur un lien hypertexte vers une URL de repli.
Cette URL doit être paramétrable dans la configuration Apache.
Si mod_cas protège des pages applicatives, celles-ci doivent alors elles-mêmes gérer leur fin de session (elle doivent le faire avec ou sansmod_cas).
Note 1 : toutes les directives actuelles de mod_cas ne peuvent s'appliquer qu'au serveur auquel ils se réfèrent. La nouvelle directive nécessaire doit pouvoir s'appliquer à n'importe quelle partie d'un serveur web (dans un <Directory>, un <Location> ou éventuellement un <File>). Cela implique des modification non négligeables dans le source de mod_cas.
Note 2 : lorsque cette directives sera absente, une solution sera de donner comme solution de repli l'URL courante sans les paramètres POST.
Les autres librairies clientes gèrent leur propre session applicative, et donc leur fin de session (comme pour mod_cas, affichage d'un message d'erreur et proposition d'un lien hypertexte). Une URL de repli doit pouvoir être fournie aux librairies lors de leur initialisation (sans quoi elle proposeront de retenter la requête sans paramètre POST).
| Création : 3 juillet 2003 - Pascal Aubry (Université de Rennes 1) | |
|
Modifications : |