Systèmes de notification

Depuis la version 0.9.4, LemonLDAP::NG peut être utilisé pour notifier des messages aux utilisateurs : si un utilisateur a un message, celui-ci est affiché lorsqu'il accède au portail. Si le message contient des cases à cocher, l'utilisateur doit toutes les cocher, sinon il ne peut obtenir de cookie de session.

Depuis la version 1.1.0, un explorateur de notifications est disponible dans le manager, et les notifications peuvent être faites pour tous les utilisateurs, avec possibilité d'affichage conditionnel. Lorsque l'utilisateur accepte la notification, la référence est stockée dans ses données de session persistentes.

Il suffit d'activer les notifications dans le manager (Paramètres généraux > Paramètres avancés > Notifications > Activation) ou dans lemonldap-ng.ini :

[portal]
notification = 1

Par défaut, les notifications sont stockées dans la même base de données que la configuration :

• si “File” est utilisé et que “dirName” vaut /usr/local/lemonldap-ng/conf/, les notifications seront stockées dans /usr/local/lemonldap-ng/notifications/
• si “CDBI” ou “RDBI” est utilisé, les notifications sont stockées dans la même base de données que la configuration et la table est nommée “notifications”.
• si “LDAP” est utilisé, les notifications sont stockées dans la même arborescence que la configuration et la branche est nommée “notifications”.

On peut changer les paramètres par défaut en utilisant les paramètres “notificationStorage” et “notificationStorageOptions” avec la même syntaxe que les paramètres de stockage de la configuration. pour ce faire dans le manager, aller dans Paramètres généraux > Paramètres avancés > Notifications.

Les paramètres pour le backend File sont les mêmes que ceux du backend de configuration File.

mkdir /usr/local/lemonldap-ng/notifications/
chown www-data /usr/local/lemonldap-ng/notifications/

Pour résumer les options disponibles :

• dirName : répertoire dans lequel sont stockées les notifications.
• fileNameSeparator : séparateur de nom de fichier.

Les paramètres pour le backend DBI sont les mêmes que ceux du backend de configuration DBI.

CREATE TABLE notifications (
  DATE datetime NOT NULL,
  uid VARCHAR(255) NOT NULL,
  REF VARCHAR(255) NOT NULL,
  cond VARCHAR(255) DEFAULT NULL,
  xml longblob NOT NULL,
  done datetime DEFAULT NULL,
  PRIMARY KEY (DATE, uid,REF)
)

Pour résumer les options disponibles :

• dbiChain : chaîne de connexion DBI.
• dbiUser : utilisateur DBI.
• dbiPassword : mot-de-passe DBI.
• table : nom de la table des notifications.

Les paramètres pour le backend LDAP sont les mêmes que ceux du backend de configuration LDAP.

Pour résumer les options disponibles :

• ldapServer : URL du serveur LDAP.
• ldapBindDN : utilisateur LDAP.
• ldapBindPassword : mot-de-passe LDAP.
• ldapConfBase : DN de la branche des notifications.

Le module de notifications utilise une carte blanche pour gérer les notifications destinées à tous les utilisateurs. The default value of this wildcard is allusers, but you can change it if allusers is a known identifier in your system.

Pour le changer, aller dans Paramètres généraux > Paramètres avancés > Notifications > Carte blanche pour tous les utilisateurs, et mettre par exemple alluserscustom.

Ainsi, créer une notification pour alluserscustom affichera la notification à tous les utilisateurs.

La transformation entre le texte XML d'une notification et l'affichage HTML est faite par XSLT. Le fichier XSLT par défaut est portal/skins/common/notification.xsl. On peut créer son propre fichier XSLT et le stocker à un autre endroit, par exemple /etc/lemonldap-ng. Configure ensuite le nouveau fichier XSLT dans le manager, aller dans Paramètres généraux > Paramètres avancés > Notifications > Fichier XSLT personnalisé et mettre par exemple /etc/lemonldap-ng/notification.xsl.

Les notifications sont des fichiers XML contenant :

• élément(s) <notification> :
  • Attibuts requis :
    • date : date de création (format AAAA-MM-JJ)
    • ref : une référence qui peut être utilisée plus tard pour connaître ce qui a été notifié et quand
    • uid : le nom de connexion de l'utilisateur (il doit correspondre à l'attribut utilisé dans le paramètre whatToTrace, uid par défaut), ou la carte blanche (par défaut : allusers) si la notification doit être affichée à tous les utilisateurs.
  • Attributs optionnels :
    • condition : condition pour afficher la notification, peut utiliser toutes les variables de session.
  • Éléments subordonnés :
    • <title> : titre à afficher : sera inséré dans la page HTML encadré dans <h2 class=“notifText”>…</h2>
    • <subtitle> : sous-titre : sera inséré dans la page HTML encadré dans <h2 class=“notifText”>…</h2>
    • <text> : paragraphe à afficher : sera inséré dans la page HTML encadré dans <p class=“notifText”>…</p>
    • <check> : paragraphe à afficher avec une case à cocher : sera inséré dans la page HTML encadré dans <p class=“notifCheck”><input type=“checkbox” />…</p>

Exemple :

<root>
<notification uid="foo.bar" date="2009-01-27" reference="ABC">
<title>Vous avez de nouvelles autorisations</title>
<subtitle>Application 1</subtitle>
<text>Vous êtes autorisé à accéder à appli-1</text>
<subtitle>Application 2</subtitle>
<text>Vous êtes autorisé à accéder à appli-2</text>
<subtitle>Acceptation</subtitle>
<check>Je reconnais savoir que je peux accéder à appli-1 </check>
<check>Je reconnais savoir que je peux accéder à appli-2 </check>
</notification>
<notification uid="allusers" date="2009-01-27" reference="disclaimer" condition="$ipAddr =~ /^192/">
<title>Ceci est votre premier accès à ce système</title>
<text>Soyez sage et ne le cassez pas.</text>
<check>Bien sûr, je ne suis pas méchant !</check>
</notification>
</root>

Dans le manager, cliquer sur l'explorateur des notifications et ensuite sur le bouton Créer.

Remplir ensuite tous les champs pour créer la notification. Seule la condition n'est pas exigée.

Lorsque tout est bon, cliquer sur Sauver.

Les nouvelles notifications peuvent être insérées en utilisant des requêtes SOAP (décrites dans le fichier WSDL généré par l'utilitaire buildPortalWSDL). Pour activer SOAP sur le portal :

• Activer SOAP dans Paramètres généraux » Paramètres avancés » SOAP
• Activer le service SOAP de notifications dans la configuration Apache :

# SOAP functions for notification insertion (disabled by default)
<Location /index.pl/notification>
    Order deny,allow
    Deny from all
    Allow from 192.168.2.0/24
</Location>

#!/usr/bin/perl
 
use SOAP::Lite;
use utf8;
 
my $lite = SOAP::Lite
        ->uri('urn:Lemonldap::NG::Common::CGI::SOAPService')
        ->proxy('http://auth.example.com/index.pl/notification');
 
 
$r = $lite->newNotification(
'
<root>
<notification uid="foo.bar" date="2009-01-27" reference="ABC">
<text> You have been granted to access to appli-1 </text>
<text> You have been granted to access to appli-2 </text>
<check> I know that I can acces to appli-1 </check>
<check> I know that I can acces to appli-2 </check>
</notification>
</root>
');
 
if ( $r->fault ) {
    print STDERR "SOAP Error: " . $r->fault->{faultstring};
}
else {
    my $res = $r->result();
    print "$res notification(s) have been inserted\n";
}

On peut également effacer certaines notifications avec SOAP, si SOAP est activé :

#!/usr/bin/perl
 
use SOAP::Lite;
use utf8;
 
my $lite = SOAP::Lite
        ->uri('urn:Lemonldap::NG::Common::CGI::SOAPService')
        ->proxy('http://auth.example.com/index.pl/notification');
 
 
$r = $lite->deleteNotification('foo.bar', 'ABC');
 
if ( $r->fault ) {
    print STDERR "SOAP Error: " . $r->fault->{faultstring};
}
else {
    my $res = $r->result();
    print "$res notification(s) have been deleted\n";
}

Il suffit d'insérer une notification et de se connecter au portail en utilisant le même UID. Le message sera affiché.

Essayer alors de créer une notification globale (à l'utilisateur “allusers”), et se connecter avec n'importe quel compte, le message sera affiché.