Il est nécessaire d'ajouter l'attribut server_principal. Reportez-vous au fichier de création des tables correspondant à votre type dans le dossier db.

Depuis la version 4.3 du canal, il est possible de saisir soi-même le libellé de l'espace que l'on ajoute dans ses espaces préférés. Pour cela, il est nécessaire d'ajouter l'attribut label. Reportez-vous au fichier de création des tables correspondant à votre type dans le dossier db.

De plus, le foreign key est à supprimer pour les bases de données déjà existantes.

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, il faut tout d'abord définir une balise <SERVER>. Ensuite, au sein d'un serveur, on peut définir plusieurs balises <SPACE>. Voyons sa structure :

<SPACES personalization="true | false">
	<SERVER
		url="http://URL:PORT/CONTEXT/"
		
		serverType="webdav | cifs"
		
		authenticationMode="trusted | asked"
		login="admin"
		password="trusted"
	>

		<PARAMETER name="aclNamespace" value="DAV:"/>
		<PARAMETER name="aclUserPrefix" value="/slide/users/"/>
		<PARAMETER name="aclGroupPrefix" value="/slide/roles/"/>
		<PARAMETER name="aclUportalGroup" value="uPortal"/>
		<PARAMETER name="aclSecurity" value="/slide/roles/local/root"/>
		
		<PARAMETER name="cifsDomain" value=""/>
		<PARAMETER name="cifsResolveOrder" value="DNS,BCAST"/>
		<PARAMETER name="cifsDisablePlainTextPassword" value="false"/>
		
		<PARAMETER name="unauthenticatedServerUrl" value="http://PUBLIC_URL:PORT"/>
		<PARAMETER name="injacPreviewUrl" value="http://URL:PORT/injac/preview"/>

		<SPACE
			key="home_dir_space_1_key"
			label="Espace à définir"
			
			path="chemin/vers/le/répertoire"
			pathRegexp="^(/slide/files)/.*:^(.).*:^/slide/files/(.).*:^(.).*:^/slide/files/(..).*:^(.).*:^/slide/files/(.*)"
			pathRegexpSeparator=":"
			
			actionType="classic | injac"
		
			sharing="simple | complex | none"
			obliged="true | false"
			showQuota="true | false"
			allowPublicSharing="true | false"
		>
				<AUTHORIZATION operator="or">
					<ALLOWED attribute="attribut_uportal" value="valeur_de_l_attribut"/>
					<ALLOWED attribute="portal_group" value="pags.mon_pags"/>
				</AUTHORIZATION>
		</SPACE>

	</SERVER>
</SPACES>

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 canal, 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:

Dorénavant, le contexte devra absolument être défini dans le path. En reprenant l'exemple précédent, la syntaxe doit donc être:

De plus, l'url ne doit pas se terminer par le caractère "/".

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:

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

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, sachant qu'il aura alors la possibilité de le modifier.

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.

<permission subjectUri="/users/adminLogin" actionUri="all" negative="false"/>

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

Pour chaque espace, il est possible de dire si le serveur supporte les ACL, c'est-à-dire les droits donnés 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, aclGroupPrefix, aclUportalGroup et aclSecurity devront OBLIGATOIREMENT être renseignés.

Par exemple, pour un serveur Slide, <PARAMETER name="aclNamespace" value="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.

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.

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/.

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.

Cet attribut correspond à une ACL de sécurité lorsque l'on gère les droits dans le canal:

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

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. OPTIONNEL. Exemple:

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

Ceci est utilisé si on veut utiliser l'unicode pour le serveur CIFS désigné. Les valeurs sont true ou false. OPTIONNEL.

Utilisé pour préciser l'encodage utilisé sur le serveur. OPTIONNEL. Exemple:

Utilisé pour préciser que l'on veut afficher tous les fichiers ou dossiers cachés en mode CIFS. OPTIONNEL. Exemple:

Utilisé pour préciser que l'on veut afficher certains fichiers ou dossiers cachés en mode CIFS. Chaque valeur doit être séparée par une virgule. OPTIONNEL. Exemple:

Lorsque l'on autorise les partages dans un espace, l'utilisateur peut rendre publique un de ses répertoires. Si c'est le cas, on peut donner un lien vers ce répertoire en mode non authentifié. Cette variable est optionnelle.

L'URL que doit contenir cette variable correspond donc à l'URL du serveur WebDAV ESUP en mode Unauthenticated. Attention à ne pas mettre le contexte dans la variable. Exemple:

Lorsque l'on travaille dans un espace inJAC, il est possible d'avoir une prévisualisation des documents non encore publiés. En indiquant ici l'URL de prévisualisation du moteur de rendu, il y aura une icône devant le document permettant d'accéder à son rendu (optionnel). Exemple:

A partir de la verson 4.3, cet attribut devient obligatoire. Il doit contenir une clef unique pour chaque espace défini.

Depuis cette version, il est possible de rendre optionnel un espace depuis le fichier de configuration. Dans ce cas d'utilisation, les utilisateurs vont pouvoir s'affecter ces espaces via l'interface de sélection associée dans le canal. L'affectation se fait alors dans la base de données en mémorisant la valeur de la clef définie ici. Lorsque vous utilisez un espace optionnel, il est donc IMPERATIF de ne JAMAIS changer la valeur de cette clef dans le fichier de configuration.

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

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".

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 à "/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.

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, prenons 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/(.*)"

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

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.

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" et si "serverType=webdav" et que ce serveur est un serveur WebDAV ESUP).

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

Pour utiliser le partage dans un espace, il faut dont définir l'attribut sharing. Pour cela, plusieurs valeurs sont possibles:

Tout comme on pouvait le faire en utilisant le canal d'administration, on peut à partir de la version 4.3 du canal rendre un espace optionnel pour les utilisateurs auxquels cet espace est destiné. Si l'attribut n'est pas défini, c'est true qui est pris par défaut.

Notons que pour utiliser cette option, il faut que personalization="true" dans la balise <SPACES>.

Dans les versions précédentes à la version 4.3, l'affichage du quota disponible dans les espaces était affiché obligatoirement dès que l'information était disponible. A partir de la version 4.3, cet affichage peut être optionnel:

Lors du partage d'un espace, l'utilisateur a la possibilité de rendre son espace public. Ceci est rendu optionnel à partir de la version 4.3:

Cet attribut permet d'associées entre elles les balises <ALLOWED> avec un opérateur ET ou OU. Si l'attribut n'est pas défini, c'est OU qui est pris par défaut.

Le nom de l'attribut uPortal à vérifier. On peut également tester sur la valeur d'un groupe uPortal de l'utilisateur. Dans ce cas, attribute="portal_group".

Ceci représente la valeur que doit avoir l'attribut attribute de l'utilisateur pour que celui-ci puisse voir l'espace. Dans le cas où attribute="portal_group", on mettra la clef d'un groupe uPortal comme par exemple value="pags.mon_pags".

L'url du serveur que l'on veut mapper. Pour être sûr de la syntaxe, vous pouvez tester l'affichage qui est mis lorsque cette balise n'est pas utilisée.

Ceci représente le libellé à afficher à la place de l'URL. Il est possible de ne rien afficher à l'utilisateur, pour cela, il faut remplir le champ url et laisser une chaîne vide dans mapping.

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

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

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

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.

Contient la liste des noms d'annuaires accessibles dans l'interface de partage, d'injac, ou d'administration du canal. Tous les noms doivent être séparés par une virgule.

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

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. Votre portail doit aussi contenir la servlet HTTPSGateway.

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.

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

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.

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 invisibles à l'utilisateur.

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".

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

Label affiché au gestionnaire lors de son choix.

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.

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

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

Représente le type de saisie, cet attribut peut prendre 3 valeurs:

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 de la valeur attendue pour la méta-donnée. Les valeurs possibles sont string et date.

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

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".

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

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

Il est possible de définir un format pour les méta-données à saisir. Pour cela, 2 possibilité: