Description des mécanismes permettant l'interaction entre le portail et les autres sites du CDS

Le problème à résoudre est de pouvoir ajouter sur les pages de VizieR et SIMBAD des options qui permettent à l'utilisateur de sauvegarder certains résultats sur son compte du portail.

L'identification du compte se fait par :

• le cookie donnant l'identifiant du compte anonyme de l'utilisateur
• le cookie donnant l'identifiant du compte personel, si l'utilisateur a coché la case "remember me" lors du dernier login
• la possibilité de s'identifier par un bouton "Login", tout comme sur le portail.

Il faudrait que l'identification sur l'une des pages serve automatiquement sur les autres pages.

Le diagramme ci-dessous montre les interactions qui sont nécessaires pour permettre la récupération de l'identification d'un utilisateur lorsqu'il navigue entre les différents services. Le problème principal vient de l'interdiction de lire des cookies d'un autre domaine, ce qui empêche de lire le cookie du domaine du portail GWT sur une page fournie par le serveur VizieR.

Description des intervenants :

• Client : c'est le navigateur de l'utilisateur, sur son propre poste.
• Serveur VizieR : c'est le serveur d'un service du CDS, ici VizieR, mais cela pourrait aussi être SIMBAD. Ce serveur se trouve soit au CDS, soit n'importe où sur l'Internet, dans le cas d'un miroir.
• CDS Portal : c'est le serveur qui s'occupe des données du portail. Il contient les servlets qui fournissent les informations aux formats XML ou JSON. Les informations sont les données rendues par les services Sesame, Aladin, VizieR ou SIMBAD. C'est aussi ce serveur qui contient la base de données des utilisateurs, ainsi que la connection vers le serveur de stockage des données sauvegardées (iRods).
• GWT Portal : c'est le serveur qui fournit l'interface du client du portail. C'est sur le domaine de ce serveur qu'est stocké le cookie principal identifiant l'utilisateur.

Au départ, l'utilisateur a chargé une page du serveur VizieR sur laquelle se trouvent des données qu'il aimerait sauvegarder sur le serveur du portail. Pour cela il faut qu'il soit identifié au niveau du portail. Les différentes étapes sont :

1. demande de login (http://vizier/login). Lors de cette requête, il se peut qu'il y ait déjà des cookies cdsAnonymousUserid ou bien cdsUserid.
2. si l'un ou l'autre cookie est présent, sa validité est testée en envoyant une requête au serveur CDS. Si l'identification est bonne, on saute les étapes 3 à 7, et l'on peut passer à la sauvegarde des infos de l'étape 8. Si l'identification n'est pas bonne, il faut récupérer les identifiants du domaine du serveur GWT.
3. le serveur VizieR envoie donc au client une instruction de redirection en donnant l'url actuelle comme origine : http://GWTPortal/login?origin=http://vizier/login
4. Le serveur GWT reçoit une demande de login qui devra être retransférée. Il récupère aussi depuis le client les cookies éventuels mis sous son nom de domaine (cdsAnonymousUserid ou bien cdsUserid)
5. le serveur GWT vérifie la validité de l'identification auprès du serveur CDS, ou bien à défaut, crée un nouvel utilisateur anonyme. Dans ce cas, il met à jour les cookies pour le domaine du portail GWT.
6. le serveur GWT donne une instruction de redirection vers la page d'origine, en lui joignant les informations de login : http://vizier/login?name=anonymous&id=xxxxxx
7. le serveur vizier reçoit maintenant une demande de login, qu'il distingue de celle de l'étape 1, parce que les informations de login sont fournies en argument. Il répond maintenant avec les données normales de la page (qui peuvent être vide, à voir). Mais l'important est qu'il met en place des cookies identifiant l'utilisateur auprès du serveur CDS.
8. en utilisant les informations des cookies pour identifier l'utilisateur, le client s'adresse au serveur CDS pour lui envoyer les données à sauvegarder.

Il y a plusieurs points qui permettent des variations.

• les cookies entre les domaines de VizieR et de GWTPortal peuvent être désynchronisés. Il faut bien voir que si un utilisateur utilise plusieurs services du CDS sur des domaines différents (imaginons un miroir VizieR, un miroir SIMBAD et le portail GWT), il peut y avoir autant de cookies, qui pourraient avoir des valeurs différentes. Dans ce cas l'utilisateur ne sauvegarde pas les données sur le compte auquel il s'attend. Un moyen d'éviter ceci est peut-être de toujours ignorer les cookies à l'étape 1. Cela signifie le passage systématique par les étapes 1 à 7 avant de passer à l'étape 8. Dans ce cas, il n'y a qu'un seul endroit où des cookies sont stockés de façon continue : sur le domaine du portail GWT.

• la requête http://vizier/login peut être une requête HTTP normale. Mais cela peut aussi être une requête AJAX, sauf s'il y a des contraintes dues aux redirections qui sont faites. Cela ne change rien à l'architecture décrite.

-- PascalWassong - 27 Aug 2008