Groupe 2F (stockage)

Date de création : 7 avril 2005
Dernière modification :
Diffusion : internet

Installation du Canal Stockage V4.0


ATTENTION: Notez que le canal en V4 est actuellement en RC, et donc en phase de tests par plusieurs établissements. Une nouvelle version, dont la base de données change en grande partie, est en cours de développement. Il est donc déconseillé de le mettre en production, avec l'option de partage, pour le moment.

Présentation

Le Canal Stockage permet la gestion de documents au travers un espace de stockage personnalisé et/ou partagé.

Dans le cadre du développement du projet inJAC, le canal a été enrichi afin de gérer des fonctionnalités avancées comme la navigation entre plusieurs espaces de stockage, la gestion des droits …

Pré-requis

Dans la mise en place de la gestion des droits, le Canal Annuaire est utilisé pour sélectionner les utilisateurs. Il est donc nécessaire d'installer ce Canal avant d'installer le Canal Stockage.

Le canal permet l'accès à une base de données pour le partage de documents, il est nécessaire de déployer le MAG, car le Canal Stockage utilise le système d'accès à des bases de données de celui-ci.

Une propriété du canal permet de passer en mode HTTPS lors de la saisie du mot de passe. Si vous utilisez cette option, vous devez vous assurer que votre version du portail possède la servlet HTTPSGateway utilisée. Elle est incluse dans les distributions esup-portail issues d'uportal 2.4 à partir de février 2005.

Installation

L'installation du Canal Stockage se repose sur les actions suivantes:
    - Recopie des libraires utilisées
    - Configuration du Canal
    - Déploiement du Canal

Recopie des librairies utilisées

Ce canal utilise les librairies :

    - commons-httpclient.jar (pour ceux qui utilisent un accès DAV)
    - jakarta-slide-webdavlib-2.4.1.jar (pour ceux qui utilisent un accès DAV)
    - jdom-1.0.jar (pour ceux qui utilisent un accès DAV)
    - esup-acl-manager-1.0.4.jar (pour ceux qui utilisent un accès DAV avec inJAC ou le partage de documents)

    - jcifs-1.1.7.jar (pour ceux qui utilisent un accès CIFS)

    - db-ojb-1.0.1.jar

Ces librairies ne sont pas fournies par défaut avec le package uPortal esup. Il est donc nécessaire d'ajouter manuellement celles dont vous avez besoin, suivant l'utilisation du canal, à la librairie de votre portail.
Celles-ci se trouve dans le répertoire lib du package CStockage.


Pour l'accès à la base de données pour le partage de documents, nous verrons par la suite qu'il est possible d'utiliser un pool de connexions JNDI ou une connexion JDBC classique. Le répertoire lib du package CStockage contient donc 3 drivers JDBC nécessaires.
    - mysql-connector-java-3.0.15-ga-bin.jar (MySQL)
    - pg74.1jdbc3.jar (Postgresql)
    - oracle_jdbc_classes12.jar (Oracle)
Suivant le SGBD que vous utilisez, il vous faut recopier le bon driver dans la librairie de votre Tomcat.


Configuration du Canal

Configuration générale du Canal

La configuration générale du Canal Stockage se fait via le fichier properties/CStockage.xml

Structure générale

La structure générale du fichier de configuration du canal est la suivante:

<CHANNEL_CONFIGURATION>			<!-- Racine du fichier de configuration -->

<SERVER_ACCESS_CLASS> <!-- Définition des classes permettant l'accès à différents types de serveurs -->
<ACCESS/>
</SERVER_ACCESS_CLASS>

<CHANNEL_ACTION_CLASS> <!-- Les actions possibles du Canal liées à chaque espace -->
<ACTION/>
</CHANNEL_ACTION_CLASS>

<SPACE_ATTRIBUTES_CHECKED> <!-- Liste des attributs de la balise SPACE dont on vérifie si la valeur est de la forme {...} -->
<ATTRIBUTE/>
</SPACE_ATTRIBUTES_CHECKED>

<SPACES> <!-- Les espaces accessibles via le Canal -->
<SPACE/>
</SPACES>

<LDAP_ACCESS/> <!-- Paramètres d'accès au LDAP -->

<DATABASE_ACCESS> <!-- Paramètres d'accès à la base de données -->
<pool/>

</DATABASE_ACCESS>

<AUTHENTICATION/> <!-- Paramètres liés à l'authentification -->

<DEFAULT_OPTIONS_INTERFACE/> <!-- Paramètres divers de suppression -->

<INVISIBLE_FILES> <!-- Définition des fichiers invisibles dans le Canal -->
<REG_EXP/>
</INVISIBLE_FILES>

<ALLOWED_DOCUMENTS/> <!-- Format que les documents doivent respecter -->

</CHANNEL_CONFIGURATION>
Nous pouvons voir apparaître en caractères gras et orange les options de configuration qui doivent être éditées par l'administrateur du portail. Les autres balises sont destinées aux développeurs du canal et ne doivent en aucun cas être modifiées.

Voyons en détail ces différentes parties:

Définition des espaces

Chaque espace de stockage accessible dans le Canal Stockage se configure au sein de la balise <SPACES>

personalization

Cet attribut permet de dire si on utilise la fonction de personnalisation des espaces dans le Canal. Nous verrons que dans un espace classique, nous pouvons utiliser la fonction de partage de dossiers. Cet attribut permet alors de dire si on utilisera ce mode dans le canal. Pour l'utiliser, la valeur doit être à true, sinon à false. Si la valeur est "true", il faut absolument avoir configuré l'accès à la base de données via la balise "DATABASE_ACCESS".


Pour chaque espace à définir, une balise <SPACE> est à décrire. Voyons sa structure :
<SPACES personalization="true">
<SPACE
label="Espace à définir"
url="http://URL:PORT/CONTEXT/"

path="chemin/vers/le/répertoire"
pathRegexp="^(/slide/files)/.*:^(.).*:^/slide/files/(.).*:^(.).*:^/slide/files/(..).*:^(.).*:^/slide/files/(.*)"
pathRegexpSeparator=":"

serverType="webdav | cifs"
actionType="classic | injac"

authenticationMode="trusted | asked"
login="admin"
password="trusted"

sharing="true | false"

manageAcl="true | false"
aclNamespace="DAV:"
aclUserPrefix="/slide/users/"
aclGroupPrefix="/slide/roles/"
aclUportalGroup="uPortal"

cifsDomain=""
cifsResolveOrder="DNS,BCAST"
cifsDisablePlainTextPassword="false"

>
<ALLOWED
attribute="attribut_uportal"
value="valeur_de_l_attribut"
/>
</SPACE>
</SPACES>


Balise <SPACE>

label

Intitulé de l'espace qui sera affiché à l'utilisateur dans sa liste déroulante de choix


url

URL d'accès au serveur. Par exemple: http://localhost:8080/slide/ dans le cas d'un serveur DAV.
Pour l'utilisation en mode CIFS, sur un serveur Samba par exemple, le type d'URL est de la forme smb://votre_serveur ou smb://192.192.192.192.

Dans les versions précédentes du portail, lors de l'utilisation d'un serveur avec contexte, comme le serveur Slide par exemple, il était possible de définir ce contexte dans l'url ou dans le path.
Nous pouvions avoir les 2 syntaxes qui suivent:
    - url="http://localhost:8080/slide" et path="/files/"
    - url="http://localhost:8080" et path="/slide/files"

Dorénavant, le contexte devra absolument être défini dans le path. En reprenant l'exemple précédent, la syntaxe doit dont être:
    - url="http://localhost:8080" et path="/slide/files"


path

Chemin d'accès au répertoire visé dans cet espace.
Un exemple de chemin peut être "/files/mon_espace/".

La gestion des espaces peut se faire à travers des attributs uPortal mis entre accolades. Mis entre accolades, l'attribut est remplacé automatiquement par sa valeur.
Par exemple, nous pouvons utiliser l'attribut username correspondant au login de la personne afin de définir un espace de travail personnel.  Le path de cet espace personnel serait alors "/{username}". Il est également possible de cette manière d'accéder à des espaces de travail partagés par tous les étudiants d'une même promotion, il suffit pour cela d'utiliser l'attribut stockant le code étape de l'étudiant.

Pour un accès absolu à un répertoire, dans le cas d'un serveur slide par exemple, le path est de la forme:
path="/files/y/yc/ycolmant" ou path="/files/t/tn/ycolmant" suivant le hachage qui a été défini sur le serveur au moment de la création des "home dir".

Lors de l'utilisation du mode d'authentification "asked", il est possible de changer le path en fonction du login saisi par l'utilisateur. En effet, dans ce mode, on peut laisser le choix à l'utilisateur de saisir un login en plus du mot de passe requis. Dans ce cas, en utilisant la chaine "{storageFormLogin}" dans le path, ce qui est entre accolade sera automatiquement replacé par le login saisi par l'utilisateur.
Ceci peut être utile dans le cas d'un accès CIFS où le chemin d'accès sur le serveur CIFS est différent du login uPortal. Dans ce cas, on pourra mettre, par exemple, path="/home/{storageFormLogin}" dans le fichier de config, et si l'utilisateur saisi le login "yohan" dans le formulaire de connexion, le path sera automatiquement transformé en "/home/yohan".


pathRegexp

Il est possible d'utiliser une expression régulière pour la transformation du path. Par exemple, si nous voulons reproduire un système de hachage depuis le canal.

Prenons l'exemple d'un serveur Slide où les espaces personnels des utilisateurs sont accessibles à "/slide/files/y/yc/ycolmant". Dans le canal, nous ne connaissons que "/slide/files" et "ycolmant", et pour ne pas implémenter "en dur" la logique de redirection, ceci peut être fait par une expression régulière. Voyons la logique pour l'exemple donné.

Puisque nous ne connaissons que "/slide/files" et "ycolmant", fixons le path à path="/slide/files/ycolmant".
Le traitement de ce chemin va être fait en 7 étapes par 7 expressions régulières différentes, chacune appliquée sur le path. Chaque traitement se fait indépendement des autres, et chaque nouveau résultat est concaténé au résultat précédent.

Expression 1: "^(/slide/files)/.*"
    Le traitement de cette expressions nous donne le résultat "/slide/files"
Expression 2: "^(.).*"
    Le traitement de cette expressions nous donne le résultat "/"
Expression 3: "^/slide/files/(.).*"
    Le traitement de cette expressions nous donne le résultat "y"
Expression 4: "^(.).*"
    Le traitement de cette expressions nous donne le résultat "/"
Expression 5: "^/slide/files/(..).*"
    Le traitement de cette expressions nous donne le résultat "yc"
Expression 6: "^(.).*"
    Le traitement de cette expressions nous donne le résultat "/"
Expression 7: "^/slide/files/(.*)"
    Le traitement de cette expressions nous donne le résultat "ycolmant"

La concaténation de tous ces résultats nous donne bien ce que l'on attendait: "/slide/files/y/yc/ycolmant".

Toutes ces expressions régulières peuvent être assemblées en utilisant un caractère de séparation, prenous pour notre exemple le ":".

Pour reproduire la description précédente, il suffit alors de donner à l'attribut pathRegexp comme valeur la concaténation de toutes les expressions régulières séparées par un caractère choisi. Ce caractère étant précisé par l'attribut pathRegexpSeparator:
pathRegexp="^(/slide/files)/.*:^(.).*:^/slide/files/(.).*:^(.).*:^/slide/files/(..).*:^(.).*:^/slide/files/(.*)"

Pour que tous les utilisateurs puissent être associés à cette expression régulière, il ne faut donc pas mettre "/slide/files/ycolmant", mais "/slide/files/{username}" dans le champ "path". Ainsi, cette transformation sera effectuée pour la valeur de "username" de chaque utilisateur.

Pour le hachage inversé (/slide/files/t/tn/ycolmant), le champ pathRegexp doit être formé comme suit:
pathRegexp="^(/slide/files)/.*:^(.).*:^/slide/files/.*(.):^(.).*:^/slide/files/.*(.):^/slide/files/.*(.).:^(.).*:^/slide/files/(.*)"


pathRegexpSeparator

Comme expliqué dans la description de l'attribut pathRegexp, pathRegexpSeparator est utilisé pour séparer chaque expression régulière.


serverType

Cette version du canal peut prendre en compte d'autres systèmes de stockage que DAV, comme par exemple CIFS. Pour cela, il faut renseigner l'attribut serverType avec la valeur définie dans les balises <SERVER_ACCESS_CLASS>. Dans cette version, les valeurs possibles sont webdav ou cifs.


actionType

Le canal a été enrichi avec différents modes d'utilisation. Il existe le mode par défaut qui est le mode classic, mais aussi le mode injac. Le mode injac positionné sur un espace permet l'apparition des actions particulières liées à la publication de documents dans le CMS inJAC.
Le mode classic ne demande aucune configuration particulière supplémentaire dans le canal, en revanche, si le mode injac est choisi pour un espace, nous verrons dans la suite du document les configurations particulières à faire en plus.


authenticationMode

Dans cette version du Canal, il existe deux modes d'authentification:
    - trusted
    - asked

trusted est un mode d'authentification via un mot de passe partagé par tous les utilisateurs et renseigné dans le fichier de configuration.
Pour ce mode, il est OBLIGATOIRE de renseigner l'attribut password. L'attribut login permet de forcer le cas échéant le login utilisé pour la connexion au serveur.

Le mode asked permet de demander les paramètres d'authentification de l'utilisateur à chaque connection au portail. Si ce mode est choisi pour un espace, l'utilisateur devra saisir manuellement le mot de passe pour y accéder.
Il est cependant possible de forcer le login défaut via l'attribut login. Si une valeur est donnée à cet attribut, l'utilisateur ne pourra pas modifier le champ "login" du formulaire. Si l'attribut "login" du fichier de configuration n'est pas saisi, le champ "login" du formulaire de saisie aura comme valeur son login de connexion au portail, sachan qu'il aura alors la possibilité de le modifier.


login

Il est possible en mode d'authentification trusted de forcer le login de connexion au serveur de fichiers. Si l'attribut login est renseigné, ce login sera utilisé pour toutes les connexions quelquesoit l'utilisateur qui se connecte au portail.

S'il n'est pas renseigné, le login utilisé sera celui de la connexion au portail.

Tout comme pour l'attribut "path", l'attribut "login" peut être basé sur un attribut uPortal autre que celui défini dans la balise "AUTHENTICATION/usernameAttribute". Pour cela, il suffit de mettre entre accolades le nom de l'attribut uPortal. Par exemple, login="{mail}" si pour un espace en particulier le login de connexion est l'adresse mail de l'utilisateur.


password

En mode trusted, c'est le mot de passe utilisé par tous les utilisateurs qui accèdent à cet espace.


sharing

Comme nous l'avons vu pour l'attribut "personalization", il est possible de permettre à des utilisateurs de partager des dossiers à d'autres usagers ou groupes d'usagers (uniquement si actionType="classic"). Ceci ne peut se faire, pour le moment, que pour des accès à des espaces de type WEBDAV.
Pour utiliser le partage dans un espace, il faut dont mettre sharing="true".

L'utilisation du partage nécessite tout de même la saisie des balises et attributs suivants:
    aclNamespace
    aclUserPrefix
    aclGroupPrefix
    aclUportalGroup
    DATABASE_ACCESS


manageAcl

Cet attribut est utilisé pour préciser si l'espace sait gérer ou pas les ACL, et si elle sait les gérer, ça nous permettra de dire si on veut utiliser cette gestion ou pas. "true" veut dire que l'espace gère les ACL et que l'on souhaite utiliser cette gestion. "false" est utilisé pour dire que l'espace ne gère pas les ACL et/ou que l'on ne souhaite pas en profiter.

Cet attribut est utile lorsque l'on partage des dossiers dans un espace "classic" ou lorsqu'on utilise le mode "injac". Dans ce dernier mode, sa valeur devra toujours être à "true".
Lorsque l'on est dans le mode classique, si on utilise un serveur Slide, la valeur devra être à "true" pour le partage de document, afin de pouvoir placer les droits nécessaires.

Pour le cas de l'utilisation d'un serveur CIFS, étant donné que celui-ci ne gère pas dynamiquement les droits d'accès, le mode de partage fonctionne quelque peu différement. En effet, en mettant manageAcl="false", il est tout de même possible de partager des espaces avec d'autres utilisateurs: les informations de partages sont recopiées dans la base de données, mais le canal est incapable d'ajouter des droits d'accès aux personnes visées. Les droits devront alors OBLIGATOIREMENT être fixées en dehors du canal, par l'administrateur du serveur CIFS.
Ce type d'utilisation ne peut donc pas être utilisé en production pour tous les utilisateurs sur un serveur CIFS. Mais son utilisation devient intéressante pour l'administrateur du canal qui voudrait donner accès à certains utilisateurs, ou groupes d'utilisateurs, à un ou plusieurs espaces. L'ajout dans le canal se faisant via l'interface de partage, et l'ajout des droits se faisant en dehors du canal.

IMPORTANT: manageAcl="true" ne peut être utilisé, pour le moment, que pour un serveur Slide. Dans ce cas, il est IMPERATIF de fixer des valeurs pour les attributs aclNamespace, aclUserPrefix, aclGroupPrefix et aclUportalGroup.


aclNamespace

Pour chaque espace, il est possible de dire si le serveur supporte les ACL, c'est-à-dire les droits donné aux utilisateurs et groupes d'utilisateurs sur les ressources au sein du serveur. Par exemple, un serveur mod_dav ne supporte pas cette possibilité, tandis qu'un serveur slide l'implémente.
Dans cette version, il est possible de gérer les partages de documents et droits associés au sein d'un espace de type classic. Dans le cas où l'on souhaite profiter de cette fonctionnalité, les attributs aclNamespace, aclUserPrefix et aclGroupPrefix devront OBLIGATOIREMENT être renseignés.
Par exemple, pour un serveur Slide, aclNamespace="DAV:".
Notons que dans le cas d'un espace de type injac, il est obligatoire de prendre un serveur qui supporte les ACL, et de définir ces attributs en fichier de configuration.

aclUserPrefix

Lors de l'utilisation des ACL dans un espace donné, il est nécessaire de donner le préfixe utilisé pour la gestion des utilisateurs sur le serveur. Pour être plus clair, ce préfixe est nécessaire dans le chemin d'accès au serveur pour que celui-ci sache où placer le droit.
Dans le cas d'un serveur slide, ce préfixe vaut par défaut /slide/users/. Attention, cette valeur pouvant être modifiée lors de l'installation de slide, vérifier auprès de la configuration du serveur avant.


aclGroupPrefix

Comme pour les utilisateurs, nous donnons ici le préfixe de gestion des groupes pour les ACL au sein du serveur. Dans le cas de slide, le préfixe vaut /slide/roles/.


aclUportalGroup

Lorsque l'on écrit un droit sur le serveur Slide, on le met dans la branche correspondant aux groupes uPortal. Il faut donc renseigner ici le noeud dans l'arborescence. Par défaut, cet attribut vaut uPortal.


cifsDomain

Ceci n'est utilisé que lorsque serverType="cifs". Cet attribut correspond au domaine du serveur CIFS.


cifsResolveOrder

Une liste (chaines de caractères séparées par des virgules) de noms de méthodes de résolution de noms spécifiant quelles méthodes doivent être utilisées et dans quel ordre pour résoudre les noms d'hôtes. Les noms de méthodes possibles sont LMHOSTS, WINS, BCAST et DNS. Exemple: cifsResolveOrder="DNS,BCAST".


cifsDisablePlainTextPassword

Désactivée par défaut. Pour permettre à la bibliothèque d'accès CIFS d'utiliser des mots de passe en clair, cette propriété doit être initialisée à cifsDisablePlainTextPassword="false".



Balise <ALLOWED>

attribute

L'accès au Canal se définissant de façon globale dans le gestionnaire de canaux d'uPortal, il est possible d'affiner ceci en fixant des contraintes pour chaque espace. Pour cela, il faut définir la balse <ALLOWED>. Cette balise comporte les attributs attribute et value. Si la personne qui se connecte a, dans ses attributs uPortal, l'attribute cité avec la valeur donnée, elle verra cet espace, sinon, il lui sera masqué.

value

Ceci représente la valeur que doit avoir l'attribut attribute de l'utilisateur pour que celui-ci puisse voir l'espace.



Exemple de configuration pour un espace WEBDAV
<SPACE
label="Mes documents WEBDAV"
url="http://mon_serveur:8080/"
 
path="/slide/files/{username}"
pathRegexp="^(/slide/files)/.*:^(.).*:^/slide/files/(.).*:^(.).*:^/slide/files/(..).*:^(.).*:^/slide/files/(.*)"
pathRegexpSeparator=":"

serverType="webdav"
actionType="classic"

authenticationMode="trusted"
password="trusted"

sharing="true"

manageAcl="true"
aclNamespace="DAV:"
aclUserPrefix="/slide/users/"
aclGroupPrefix="/slide/roles/"
aclUportalGroup="uPortal"

/>


Exemple de configuration pour un espace CIFS
<SPACE
label="Mes documents CIFS"
url="smb://192.192.192.192"

path="/{storageFormLogin}"
serverType="cifs"
actionType="classic"

authenticationMode="asked"

cifsDomain="univ.fr"
cifsResolveOrder="DNS,BCAST"
cifsDisablePlainTextPassword="false"

/>



Accès au serveur LDAP

Lors de l'accès aux ACL via le Canal, il est possible de visualiser celles qui ont déja été placées précédemment.
Le mode de gestion des ACL fait que nous ne pouvons récupérer que l'identifiant de la personne ou le groupe visé par cette ACL. Pour avoir une meilleur visibilité, il est donc nécessaire de définir les paramètres d'accès au serveur LDAP pour récupérer le véritable nom de l'utilisateur.

La structure de cette balise est la suivante:
<LDAP_ACCESS 
serverUrl="ldap://ldap.univ.fr:389"
people="ou=people,dc=univ,dc=fr"
userKeyAttribute="uid"
userDisplayNameAttribute="displayName"
/>

serverUrl

L'url du serveur ldap. Typiquement cet attribut est de la forme ldap://ldap.univ.fr:389.


people

Ceci représente le dn de la branche people du LDAP.


userKeyAttribute

Attribut LDAP contenant le login de la personne connectée.


userDisplayNameAttribute

Attribut LDAP contenant le nom complet de la personne connectée à afficher. ATTENTION: le nom de cet attribut doit OBLIGATOIREMENT être défini dans le canal annuaire afin que la valeur de celui-ci puisse être passée entre les deux canaux.


Accès à la base de données

Nous avons vu qu'il est possible d'utiliser le partage de documents dans un espace "classic". Pour cela, les informations de partage sont stockées dans une base de données.

Création de la base

La première étape consiste à créer une base de données. Il existe 3 fichiers de création des tables dans le dossier db du package:
    - MySQL.sql
    - Postgres.sql
    - Oracle.sql
Utilisez celui qui concerne le SGBD que vous utilisez.

Il existe également un fichier "drop_tables.sql" permettant de supprimer les tables.


Définition du pool de connexions JNDI

Il existe 2 possibilités de connexions à la base de données depuis le canal:
    - connexion JDBC classique
    - utilisation d'un pool de connexions JNDI

Pour l'utilisation du pool, il faut précédemment le définir dans le fichier server.xml de votre Tomcat.
Il faut définir les balises Resource et ResourceParams dans le contexte uPortal. Voyez un exemple de définition du pool CStockageDb dans le fichier exemple_server.xml.

Pour finir, il faut s'assurer que le driver correspondant à votre SGBD est bien dans la librairie de Tomcat.


Définition dans le canal

La structure de la balise de configuration de l'accès à la base de données est la suivante:
<DATABASE_ACCESS 
type="JNDI | JDBC"
url="jdbc:mysql://localhost:3306/CWEBDAV"
driverClassName="com.mysql.jdbc.Driver"
username="portail_2005"
password="p_2005"
/>

type

Le type de connexion que l'on veut pour l'accès à la base de données.
La valeur est "JNDI" pour l'utilisation d'un pool de connexion, ou "JDBC" pour un accès classique.


url

Dans le cas d'un type="JNDI", l'URL représente le nom du pool. Dans l'exemple fournir, url="CStockageDb".
Pour type="JDBC", il faut donner l'URL d'accès à la base de données. Exemples:
    - jdbc:mysql://localhost:3306/cstockage (MySQL)
    - jdbc:postgresql://localhost:5432/cstockage (Postgresql)
    - jdbc:oracle:thin:@enee:1521:ISTV (Oracle)


driverClassName

Utilisé uniquement si type="JDBC". Ceci représente le nom du driver à utiliser. Suivant votre SGBD, la valeur est:
    - com.mysql.jdbc.Driver (MySQL)
    - org.postgresql.Driver (Postgresql)
    - oracle.jdbc.driver.OracleDriver (Oracle)


username

Utilisé uniquement si type="JDBC". Le login de connexion à la base de données.


username

Utilisé uniquement si type="JDBC". Le mot de passe de connexion à la base de données.


Paramètres généraux d'authentification

<AUTHENTICATION 
usernameAttribute="username"
httpsRedirection="true | false"
/>

usernameAttribute

Attribut uPortal contenant le login de la personne qui cherche à se connecter.


httpsRedirection

Lors de l'utilisation d'espaces en mode "asked", le mot de passe est demandé à l'utilisateur. Pour que le mot de passe ne circule pas "en clair" sur le réseau, on peut faire passer le portail en HTTPS au moment de l'envoi de celui-ci.

Si httpsRedirection="true", le portail passera automatiquement en HTTPS pour la saisie du formulaire de connexion. Une fois connecté, ou si vous basculez vers un espace où on ne demande pas de mot de passe, le portail repassera automatiquement en HTTP. Pour ce mode, vous devez IMPERATIVEMENT avoir un accès possible à votre portail à la fois en HTTP et en HTTPS.

Si httpsRedirection="false", l'envoi du mot de passe ne sera pas crypté et le portail ne passera jamais de HTTP vers HTTPS et vice-versa.


Paramètres divers de suppression

Dans le cas d'un accès à un espace en mode classic, il est possible de définir des options de suppression de ressources sur le serveur.

<DEFAULT_OPTIONS_INTERFACE
confirmDel="true"
allowDelNonEmptyFolder="true"
/>

confirmDel

Vaut true si on demande confirmation avant de supprimer une ressource. Si false, on supprime sans demander confirmation.


allowDelNonEmptyFolder

Permet de dire si on peut supprimer des répertoires non vides. Si true, on a le droit de supprimer des répertoires non vides, si false, il est impossible de supprimer un répertoire non vide.

Fichiers invisibles

Afin de ne pas pouvoir accéder à certains fichiers propres au serveur (comme .htaccess dans Apache), nous pouvons définir un critère "d'invisibilité" de certaines ressources.

<INVISIBLE_FILES>
<REG_EXP
pattern="^\..*"
/>
</INVISIBLE_FILES>
pattern

Expression réguliére permettant de dire quels fichiers doivent être masqué à l'utilisateur.
Dans l'exemple ^\.. les fichiers commençant par un point sont interdits.


Configuration du module inJAC

Nous avons précédemment vu que certains espaces peuvent être utilisés en mode injac. Pour l'utilisation de ce mode, il est nécessaire de définir certaines propriétés.

Structure générale

Le fichier de propriété propre à ce mode est properties/injac/injac.xml

Sa forme générale est la suivante:

<INJAC>					<!-- Racine du fichier de configuration -->

<METADATA_PROFILES> <!-- Ensemble des profiles méta-données -->
<METADATA_PROFILE/>
</METADATA_PROFILES>


<RENDERINGS> <!-- Ensemble des noms de fichiers des skins utilisables pour le rendu des documents d'un espace injac -->
<RENDERING/>
</RENDERINGS>

</INJAC>

Voyons plus en détail ces balises.

Liste de méta-données

Lors de l'utilisation du CMS inJAC, des méta-données doivent être positionnées par l'utilisateur qui cherche à soumettre ou à publier un document. Ces méta-données sont fixées par le gestionnaire de l'espace.

Pour que le traitement du gestionnaire soit le moins lourd possible, le choix qui a été fait est de définir des profils type de méta-données. Le gestionnaire n'a alors qu'à choisir le profil désiré.

Voyons la balise à éditer pour spécifier ces méta-données:

<METADATA_PROFILES>

<METADATA_PROFILE
fileName="default.xml"
label="Méta-données par défaut"
/>

</METADATA_PROFILES>

Pour chaque profile de méta-données, il faut définir une balise <METADATA_PROFILE>. Voyons les attributs qui la composent:

fileName

Cet attribut contient le nom du fichier xml qui contient tout le profile. Ce fichier doit IMPERATIVEMENT se trouver dans le dossier properties/injac/metadata. Nous verrons la forme de ce fichier dans la partie "Définitions d'un profil de méta-données".

label

Ceci est le label de ce profil qui est affiché au gestionnaire de l'espace inJAC.


Liste de feuilles de style pour rendu

Pour chaque espace, le gestionnaire peut choisir le rendu qui sera associé grace à une feuille de style. Pour cela, le gestionnaire a la possibilité de choisir ce rendu dans une liste déroulante.

Cette liste est construite via la balise suivante:

<RENDERINGS>

<RENDERING
label="Rendu par défaut"
skinFile="File.xml"
/>

</RENDERINGS>

Pour chaque skin potentiellement utilisable dans le rendu, il faut définir une balise <RENDERING>.

label

Label affiché au gestionnaire lors de son choix.


skinFile

Nom du fichier contenant le skin à utiliser pour un espace donné. Un skin est un fichier xml qui décrit le contenu optionnel, le style (fontes, couleurs) et la disposition des éléments du rendu inJAC.


Définition d'un profile de méta-données

Un format a été défini pour la définition des méta-données à saisir par l'utilisateur au moment de la soumission, ou de la publication d'un document.

La forme globale du fichier doit être de cette forme:

<?xml version="1.0" encoding="ISO-8859-1"?>

<metas>
<meta/>
</metas>

Chaque balise <meta> représente une méta-donnée à positionner lors de la soumission ou la publication d'un document.

Voyons plus précisémment sa forme.

<meta 	
name="---"
label="---"
input="text|textarea|select"
choiceList="a,b,c"
type="string|date"
required="yes|no"
level="edition|publication"
defaultValue="---"
comment="---"
format="regexp|dateFormat"
/>


name

Ceci est le nom réel de la méta-donnée au sein du serveur.


label

Un nom donné à la méta-donnée pour plus de compréhension par l'utilisateur.


input

Représente le type de saisie, cet attribut peut prendre 3 valeurs:
    - text: sera représenté par un champ de saisie de type "text" dans un formulaire HTML.
    - textarea: correspond à une zone de saisie sur plusieurs lignes
    - select: liste déroulante


choiceList

Utilisable uniquement et obligatoirement si input="select", cet attribut permet de définir la liste des choix possible pour cette méta-données. Toutes les valeurs doivent être séparées par une virgule.

type

Type de la valeur attendue pour la méta-donnée. Les valeurs possibles sont string et date.


required

Certaines méta-données peuvent être optionnelles (required="yes") et d'autres obligatoires (required="no").


level

Indique le niveau de saisir pour cette méta-donnée, c'est-à-dire la personne qui va devoir la saisir. Si level="edition", c'est le rédacteur (lors de la soumission) qui devra la saisir, tandis que ça sera l'éditeur (lors de la publication) si level="publication".


defaultValue

La méta-donnée peut prendre une valeur par défaut, c'est via cet attribut qu'elle est définie.


comment

Afin d'apporter une certaine clarté à l'utilisateur, il est possible de mettre un commentaire qui sera affiché dans le canal à côté du champ de saisie.


format

Il est possible de définir un format pour les méta-données à saisir. Pour cela, 2 possibilité:
- Si type="string", il faudra définir une expression régulière (pour un email par exemple)
- Si type="date", il daudra définir un format de date correspondant à la classe DateFormat en Java. Par exemple, "dd/MM/yyyy" pour une date du type 15/06/2004.


Remarque
Sous windows, des problèmes d'encodage des caractères accentués ont été relevés lors de l'édition de ces fichiers via l'outil notepad. Préférez l'utilisation de wordpad.



Déploiement du Canal

Préparation du déploiement : modifier le fichier build.properties en fonction de la version de portail que vous utilisez.
Lancez la commande "ant deploy" relative au fichier build.xml contenu dans le package.
Il ne reste plus qu'à l'administrateur du portail de publier le canal.