Gestion locale et globale des paramètres

Pour l’instant, les paramètres de configuration de nebule et de sylabe se font via un fichier de configuration sur le serveur.

Il sera possible plus tard de permettre la configuration de certains paramètres de façon globale, c’est à dire via un objet dédié.
Tous les paramètres ne pourront pas être globaux, à définir.

Comme d’habitude, le contenu pourra être public et/ou privé.

On peut déjà prévoir qu’un paramètre public sera mal défini et surchargé par le même paramètre mais privé. C’est une forme de défense par déception.

Authentification et mot de passe

Dans la version précédente, procédurale, de la librairie nebule en php, l’authentification était gérée via des variables de la session. On retrouvait l’ID de l’entité en cours ainsi que l’ID de la clé privée associée et le mot de passe (si déverrouillé) de cette clé privée.

Les anciennes variables :
$_SESSION['nebule_publ_entite']
$_SESSION['nebule_priv_entite']
$_SESSION['nebule_pass_entite']

Dans la nouvelle version de la librairie, en programmation orientée objet, la première variable qui référence l’entité en cours d’utilisation est toujours nécessaire.
Par contre, la variable qui référence la clé privée est encore utilisé mais n’est déjà plus vraiment indispensable puisque l’instance (l’objet au sens programmation) de l’entité contient la référence à l’ID de sa clé privée. Cet ID de clé privée est pré-calculée lors de l’initialisation de l’instance et est accessible par une fonction publique. Il est même possible que cette variable de session pour la clé privée disparaisse à terme faute d’usage.
Enfin, la variable contenant le mot de passe de la clé privée, elle, disparaît définitivement. Elle n’était renseignées que lorsque l’entité était déverrouillées. Désormès, le mot de passe, lorsque fourni, est stocké dans l’instance de l’entité en cours. Cette instance référence ainsi la clé privée et le mot de passe associé. Ce mot de passe est bien sûr vérifié lors de son enregistrement puisque c’est la seule et unique condition pour considérer l’entité comme déverrouillée, que le mot de passe soit valide sur la clé privée.

En terme de sécurité du code, c’est plus propre. Le mot de passe ne peut être consulté directement par un module malveillant comme avec une variable de session par essence globale et donc accessible partout. Cependant, le mécanisme n’est pas parfait puisqu’une lecture brute de l’instance permet d’en extraire le contenu… et donc le mot de passe. Il faudra trouver un mécanisme pour renforcer ça…
L’usage d’un sel pour le mot de passe est en cours de réflexion sachant qu’il faudra dans ce cas créer un lien pour le rendre publique. C’est un renforcement de la sécurité du mot de passe mais potentiellement une source de panne.

En terme de gestion des entités, c’est plus facile si on change vers une entité que l’on maîtrise puisque les mots de passe des entités esclaves sont accessibles et peuvent être pré-injectés dans les entités correspondantes. Et puis en cas de bascule vers une de ces entités esclaves, le retour à l’entité maîtresse est plus facile aussi puisque le mot de passe pourra rester dans celle-ci.

En terme d’évolution, il est déjà prévisible qu’une forme avancée d’un usage multi-entité verra le jour. CF Entités multiples. La pré-initialisation des mots de passes de toutes les entités sous contrôle (entités esclaves) rendra cet usage beaucoup plus facile. Pour rappel, cet usage multi-entité permettra au choix soit d’utiliser une et une seule entité à un instant donné mais de pouvoir immédiatement et facilement changer d’entité, soit d’utiliser simultanément tout ou partie des entités sous contrôle. Dans ce dernier cas, les actions seront par contre faites avec une seule entité pré-definie pour cela.

Voici la structure de la classe Entity :

class Entity extends Object
{
	const ENTITY_MAX_SIZE = 16000;
	const ENTITY_PASSWORD_SALT_SIZE = 128;
	const ENTITY_TYPE = 'application/x-pem-file';

	private $_publicKey = '';
	private $_privateKeyID;
	private $_privateKey = '';
	private $_privateKeyPassword;
	private $_privateKeyPasswordSalt;
	private $_issetPrivateKeyPassword = false;
	private $_faceCache = array();

	public function __construct(nebule $nebuleInstance, $id);
	public function __destruct();
	public function __toString();
	private function _loadEntity($id);
	private function _createNewEntity();
	private function _verifyEntity($entity);
	public function getType();
	public function getKeyType();
	public function getPublicKeyID();
	public function getPublicKey();
	private function _findPublicKey();
	public function getPrivateKeyID();
	private function _findPrivateKeyID();
	private function _findPrivateKey();
	public function setPrivateKeyPassword($passwd);
	public function unsetPrivateKeyPassword();
	public function checkPrivateKeyPassword();
	public function changePrivateKeyPassword($newpasswd);
	public function getFullName();
	public function getLocalisations();
	public function getLocalisation();
	public function getFaceID($size=400);
}

Avancement

La librairie nebule en bash évolue. Ça faisait longtemps…

Comme un nouveau fichier nebule.env est utilisé par la librairie nebule en php, en place de l’ancien env_nebule.php, il était naturel que ce fichier serve aussi à la librairie en bash. Ce fichier évolue pour intégrer des options spécifiques au bash. Certaines options sont spécifiques au php et d’autres, comme la crypto, sont communes.

Le gros changement ‘est surtout que les options ne sont plus des variables. Il est possible d’extraire directement une option de configuration au moment de l’utiliser, mais il est aussi possible d’en faire une variable, comme avant. C’est cette dernière solution qui est utilisée pour l’instant, par facilité.

Cette nouvelle version de la librairie nebule en bash sera prochainement diffusée par bachue

Mise en place d’un cache

Dans la librairie nebule de référence en php, une forme de mise en cache des résultats a été mise en place. Un certain nombre de fonctions peuvent être appelées plusieurs fois avec les mêmes paramètres. Il est plus rapide de mémoriser certains résultats par défaut même si ils ne sont plus utilisés que de relire et revérifier des liens pour retrouver les résultats.

Les gains dans les modes nav et lnk sont très sensibles, au minimum 2 à 3 fois moins de temps pour afficher une page.

La mise en cache est contrôlée par la variable $nebule_usecache.

CF : http://blog.sylabe.org/?p=488

Les variables des librairies

Une page Variables vient d’être mise en ligne. Elle regroupe les différentes variables utilisées par les librairies et modifiables par l’utilisateur (via les fichiers d’environnement), leurs valeurs par défaut ainsi qu’une description.

Sont concernées actuellement les variables en php, mais les variables en bash suivront…