Par défaut dans OpenLDAP le mot de passe utilisateur (attribut usepassword) est stocké sans cryptage.
Si on modifie le mot de passe via un fichier LDIF, on aura donc le mot de passe en clair dans l'annuaire, ce qui n'est pas sécurisé.
On peut également appliquer un algorithme de cryptage en amont (dans l'application cliente) et le transmettre à OpenLDA, qui va le stocker tel quel.
Nous avons eu récemment le besoin de notifier par mail les administrateurs de domaine, sur un service situé en haut de l'organisation (service partagé), alors que les personnes sont rattachées à des sous-domaines.
Du coup, le type de participant DOMAIN_ADMIN ne fonctionne pas, car il est rattaché au service.
Il a donc fallu développer un javascript spécifique pour arriver à nos fins. Celui-ci est finalement assez simple (une fois qu'on a réussi à naviger dans la documentation IBM...)
Par défaut dans quasiment tous les thèmes, Drupal affiche la variable $submitted, qui comprend le login de l'auteur ainsi que la date. Tout ceci sans style, de manière assez brute :
On se pose souvent la question suivante dans Drupal : comment avoir une mise en place différente pour un type de contenu spécifique ?
Si par défaut, Drupal utilise différentes suggestions (cf https://drupal.org/node/1089656), telles que : node-type, node-id, page-front, il n'utilise pas en standard un modèle de page pour un type de contenu.
Pour rappel, un template intitulé page--front.tpl.php sera utilisé pour la page d'accueil (notez bien les 2 tirets).
Lors de l'installation de redmine, le serveur http par défaut est webrick. Celui-ci n'est pas taillé pour la production, et il est recommandé d'utiliser une autre solution : soit Mongrel, soit Apache avec le module mod_passenger, qui permet d'exécuter des applications Rails.
C'est cette solution que nous allons détailler ici.
On suppose que Redmine est déjà installé, ainsi qu'un serveur apache, et que tout ceci se fait sur une Debian ou Ubuntu.
Sur les distributions type Red Hat / CentOS, SELinux (Security-Enhanced Linux) est activé par défaut.
Malheureusement, ceci empêche parfois l'installation et le fonctionnement correct de certains programmes.
Il existe plusieurs solutions pour désactiver, soit temporairement, soit une bonne fois pour toute.
Par défaut, Drupal va enregistrer les événements dans sa base de données, via le module Database Logging inclus dans le "core".
L'inconvénient majeur est de générer un nombre important d'écriture en base, ce qui impacte directement les performances, et fait grossir inutilement la base de données.
Il est bien sûr possible de désactiver complètement ces traces, mais elles peuvent révéler des soucis (notamment des fichiers inexistants, des tentatives de connexions infructueuses, etc.).