Je cherche depuis deux jours comment avoir un mécanisme de "clef obligatoire" (mandatory key) par utilisateur avec Mozilla Firefox.
Mon but est de pré-configurer des postes clients Firefox suivant l'utilisateur qui s'y connecte.
Le plus simple est de modifier le fichier "prefs.js" dans le profile utilisateur se trouvant dans le répertoire personnel de l'utilisateur. Le problème c'est que l'utilisateur aura la possibilité de modifier les paramètres. A chaque connexion il verra son paramétrage disparaître sans forcement comprendre.
Il existe un second fichier "user.js" qui prévaut sur le fichier "prefs.js". Cela signifie que l'utilisateur peut modifier les paramétrages, mais ceux-ci ne s'appliquent ni maintenant, ni après redémarrage. C'est assez perturbant.
La troisième solution est d'utiliser le mécanisme de verrou. Mais le fichier de verrou est global pour tous les utilisateurs. Impossible alors de personnaliser quoi que ce soit.
Après recherche, je suis parvenu a réalisé ce que je souhaite.
Voici la méthodologie :
Commençons par ajouter le support des "clefs obligatoires" :
Dans le fichier, /usr/lib/xulrunner-x.x.x.x/greprefs/all.js (sous Mandriva en tout cas, il est possible que ce répertoire soit directement dans le répertoire de firefox), ajouter :
pref("general.config.filename", "mozilla.cfg"); pref("general.config.obscure_value", 0);Cela permet d'ajouter le support du fichier "mozilla.cfg". C'est ce fichier qui est censé contenir les "clefs obligatoires" global pour tous les utilisateurs. L'option "obscure_value" est à "0" pour éviter l'avoir à le convertir en ROT13 (sécurité par obscurantisme inutile).
Pour avoir un support multi-utilisateur, j'ajoute dans le fichier /usr/lib/firefox-x.x.x/mozilla.cfg :
// var env_user = getenv("USER'); lockPref("autoadmin.global_config_url", "file///etc/firefox/"+env_user+".js");(attention, le "//" au début du fichier semble obligatoire).
EDIT : sous Windows, il faut visiblement : var env_user = getenv("USERNAME"); (non testé). Pour un support multi-platforme il est alors possible de faire :
if(getenv("USER") != "") { // *NIX settings var env_user = getenv("USER"); } else { // Windows settings var env_user = getenv("USERNAME"); }Il est alors possible d'avoir un fichier de configuration par utilisateur. Dans le fichier /etc/firefox/nom_de_l'utilisateur.js, mettre des clefs commençant par lockPerf (penser à la première ligne "//").
Pour les clefs, vous pouvez utiliser les informations de cette page : http://www.pcc-services.com/kixtart/firefox-lockdown.html.
Reste un soucis de taille ... à la prochaine mise à jour de Firefox ... il faudra reconfigurer le fichier all.js ...
Si quelqu'un à une solution pour cette limitation, je suis intéressé.
Après une grosse heure de corrections j'ai enfin pu importer le bâti (basé sur le cadastre) pour les communes de Mialet, Saint Jean de Serres et de Saint Christol les Alès.
Le nouveau script de récupération des données cadastrales, fonctionne plutôt bien. Que 
700 erreurs à corriger mais le résultat est vraiment chouette. Les serveurs du projet OpenStreetMap sont en train de subir les assauts de l'ensemble de la communauté des contributeurs français. Pourquoi pas vous ?
Lors des imports massifs les données sources peuvent être intégralement en majuscule ou en minuscule, il faut alors reprendre un à un tous les noms pour les écrire correctement. Cette tâche est longue et fastidieuse, pour réduire cette lourdeur j'ai écris une fonction à intégrer dans une base PostgreSQL en PL/Perl qui simplifie grandement le travail de ré-écriture. La fonction osm_capitalize suit les règles définies dans le Code officiel géographique de l'INSEE. Au vu des règles suivies la fonction n'est valide que pour les toponymes français.
Un exemple d'utilisation de la fonction, la première colonne présente le nom tels que trouvés dans un import, et la colonne de gauche le même nom passé au travers de la fonction.
Le petit pré | Le Petit Pré Le petit du champs des prés | Le Petit du Champs des Prés LE PETIT DU CHAMPS DES PRÉS | Le Petit du Champs des Prés la près d'hier | La Près d'Hier Bourg-en-bresse | Bourg-en-Bresse BOURG-EN-BRESSE | Bourg-en-Bresse l'epine | L'Epine L'EPINE | L'Epine LA ROCHE-SUR-YON | La Roche-sur-Yon CLAVANS-EN-HAUT-OISANS | Clavans-en-Haut-Oisans l'isle-jourdain | L'Isle-Jourdain PONT D'AIN | Pont d'Ain SAINT-ANDRÉ-D'HUIRIAT | Saint-André-d'HuiriatMise à jour du 26 juin : le code a migré chez Gitorious
La mairie de Guipel a fournit les données géographiques en sa possession à l'équipe de contributeurs d'OpenStreetMap j'ai été chargé de procéder à cet import, je tiens ici à remercier François, Steven et Pierre pour leur confiance. Bien que modeste dans le volume des données à traiter cet import m'a permis de toucher à une autre facette du projet OpenStreetMap. J'avais déjà étudié l'import de données automatisé avec le traitement des coordonnées des éoliennes (voir billet ci-contre) mais je n'avais pas encore manipulé de shapefile, ce qui est désormais chose faîte.
Pour se rendre compte de l'intérêt de cet import on peut comparer les deux images suivantes ; avant l'import ...
et après l'import
Cet import a été rendu possible grâce à la documentation de François Van Der Biest sur l'import de Crozon.
Si vous cherchez Guipel sur la carte en ligne c'est ici
J'ai pris beaucoup de plaisir dans l'étude et la réalisation de cet import massif, j'espère avoir l'occasion d'en réaliser d'autres très prochainement.
Que soit ici remercié la mairie de Guipel pour la fourniture de ces données, l'import n'est qu'une étape dans l'intégration de Guipel dans la carte OSM, la seconde aura lieu le samedi 19 juin 2010 avec une carto-partie sur place.