Installer

Présentation

Configuration

Indexation

Recherche

OAI

Identification

Identification des utilisateurs

Liste des actions décrites dans cette page :

sdx:login ;
sdx:loginSu ;
sdx:logout.

Concepts clés

SDX inclut des fonctionnalités de gestion d'utilisateurs et de groupes d'utilisateurs. Nous allons décrire dans cette page les actions permettant à un utilisateur consultant le site de s'identifier (login) ou de se désidentifier (logout).

Les actions SDX qui permettent de vérifier l'appartenance de l'utilisateur à un groupe (et ainsi de contrôler les accès aux différentes fonctionnalités de l'application) sont définies dans la section "Gestion des droits".

SDX stocke les informations relatives à l'utilisateur dans un cookie du navigateur. Par défaut, le consultant d'une application SDX est un utilisateur anonyme, mais le développeur d'application peut lui offrir la possibilité de s'identifier pendant toute la durée de la session où jusqu'à ce qu'il se déconnecte.

Il existe plusieurs classes d'utilisateurs :

Utilisateur anonyme: Un simple consultant n'ayant fait aucune démarche d'identification.
Utilisateur: L'utilisateur lambda d'une application. Il est possible d'intégrer un utilisateur à différents groupes d'utilisateurs, depuis le groupe de simples lecteurs jusqu'au groupe des administrateurs d'une application.
Administrateur: L'administrateur possède des droits supérieurs à celui du simple utilisateur. Son rôle est d'administrer d'une application : indexer des documents, supprimer des documents, restructurer une application, définir des utilisateurs, etc.
Super-utilisateur: Le super-utilisateur (SU) administre le serveur SDX qui héberge les applications. Il est important de noter qu'il n'a aucun droit à l'intérieur des applications. Rien n'empêche cependant de définir un utilisateur d'application ayant les mêmes paramètres d'identification que le SU.

Les utilisateurs sont définis dans le contexte d'une application SDX. Une page XSP s'exécutant toujours dans un contexte d'application, la connexion va normalement s'effectuer sur l'application courante. Il est toutefois possible de connecter un utilisateur à autre application depuis l'application courante.

Un super-utilisateur ayant un rôle différent de celui d'un utilisateur d'application, son identification doit passer par une action différente (cf. sdx:loginSu).

`sdx:login`

Cette action permet de tenter d'authentifier un utilisateur et, en cas de réussite, de le définir comme utilisateur courant. Elle n'a pas d'équivalent dans l'API-URL.

Tableau 1. Description

Code implémentant cette action	`sdx-actions.xsl`
Contexte d'utilisation	N'importe où dans `sdx:page` .
Contenu éventuel	N'importe quel élément `sdx:*` ou autre. Si l'authentification réussit, les éléments fils seront traités hormis un éventuel sous-élément `sdx:fallback`. Réciproquement, si l'authentification échoue, seul l'élément `sdx:fallback` sera exécuté.

Tableau 2. Paramètres spécifiques

Nom	Description
`id`	Le code utilisateur.	Obligatoire
`pass`	Le mot de passe. Les utilisateurs peuvent ne pas avoir de mot de passe.	Facultatif

Tableau 3. Paramètres communs

Nom Description Action de référence

app

L'identifiant de l'application où est défini l'utilisateur que l'on veut authentifier.

Par défaut, il s'agit de l'application où s'exécute la page XSP.

sdx:app

Facultatif

appbypath

Le chemin de l'application.

Par défaut, il s'agit de l'application où s'exécute la page XSP.

Au cas où les 2 paramètres seraient présents, app est prioritaire sur appbypath.

sdx:app

Facultatif

Exemple 1. Identification depuis un formulaire HTML

Dans cet exemple, on suppose que la page est exécutée à la suite de la soumission d'un formulaire à deux champs. L'un contient le code utilisateur et a pour nom code, l'autre contient le mot de passe et a pour nom mdp. L'identification va être tentée pour l'application où s'exécute la page XSP ; un traitement spécifique est prévu en cas d'échec.

 
<sdx:login idParam="code" passParam="mdp"> 
  <succes_proposer_quelque_chose/> 
  <sdx:fallback> 
    <erreur_proposer_autre_chose/> 
  </sdx:fallback> 
</sdx:login>

`sdx:loginSu`

Cette action permet d'authentifier le super-utilisateur (SU) et de le définir comme utilisateur courant.

Tableau 4. Description

Code implémentant cette action	`sdx-actions.xsl`
Contexte d'utilisation	N'importe où dans `sdx:page`
Contenu éventuel	N'importe quel élément `sdx:*` ou autre. Si l'authentification réussit, les éléments fils seront traités hormis un éventuel sous-élément `sdx:fallback`. Réciproquement, si l'authentification échoue, seul l'élément `sdx:fallback` sera exécuté.

L'action sdx:loginSu utilise les mêmes paramètres (communs et spécifiques) que l'action sdx:login.

`sdx:logout`

L'action sdx:logout permet de déconnecter l'utilisateur courant (quel que soit son niveau : utilisateur, administrateur, super-utilisateur). L'utilisateur courant devient alors un utilisateur anonyme.

La déconnexion d'un utilisateur n'a besoin d'aucune information particulière, sinon une confirmation de l'exécution de cette action.

Tableau 5. Description

Code implémentant cette action	`sdx-actions.xsl`
Contexte d'utilisation	N'importe où dans `sdx:page`
Contenu éventuel
Utilisation des paramètres communs

Tableau 6. Paramètre spécifique

Nom	Description
`logout`	Confirmation de la déconnexion. Ce paramètre n'attend qu'une valeur : `true`	Obligatoire

Exemple 2. Déconnexion

L'exemple suivant présente le code d'une XSP qui déconnecte l'utilisateur courant... sans aucune intervention de sa part. Noter l'emploi de l'élément titre qui devra être intercepté dans la feuille XSLT pour créer le titre de la page HTML.

<xsp:page>
  <sdx:page>
    <sdx:logout logout="true"/>
    <titre/>    
  </sdx:page>
</xsp:page>

Auteurs : Malo Pichot ( AJLSM ) ; Martin Sévigny ( AJLSM ) ; Pierrick Brihaye - 2003-06-04

	Home
Copyright © 2000, 2001, 2002, 2003, 2004 Ministère de la culture et de la communication, AJLSM.