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.