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 remise en place des fonctions de la librairie nebule en php orienté objet ainsi que la ré-écriture du bootstrap pour en profiter reprend pleinement.

La résolution du graphe des mises à jours des objets, c’est à dire le suivi des liens de mises à jours, est fonctionnelle. On peut donc maintenant rechercher la dernière version de la librairie ainsi que la dernière version du programme à charger par défaut.
La librairie ayant le minimum fonctionnel pour le bootstrap, elle y a été intégralement copiée. Plus tard, elle sera allégée des fonctions non utilisées. La librairie étant plus modulable, les modules non nécessaires au bootstrap ne seront simplement pas intégrés.

La cible : faire charger la librairie par le bootstrap et le programme par défaut.

Le programme sylabe est fonctionnel sur la librairie actuelle moyennant la conservation des fonctions procédurales. Ces anciennes fonctions seront progressivement transformées pour utiliser les nouvelles fonctions en programmation orienté objet… et/ou supprimées dès que sylabe aura été mis lui aussi à jour. En attendant, il intègre en bas de page les nouveaux compteurs du nouveau bootstrap.

nebule_bootstrap_-_Experimental_-_2014-11-16_10.21.26

Avancement

La ré-implémentation de la librairie en php orienté objet avance.

Un gros point de blocage vient de sauter. Il s’agissait d’implémenter la résolution d’un graphe de liens de mises à jours. L’implémentation précédente fonctionnait bien mais nécessitait une sous fonction qui s’appelait elle-même au fur et à mesure du parcours des liens u. Ici, il fallait forcément implémenter une fonction de recherche des mises à jours sur un niveau pour un objet. Mais en contre-partie, et moyennant un fonctionnement plus complexe, il a été possible de ne plus utiliser la sous-fonction auto-appelée…
Bref, c’est plus complexe à comprendre mais c’est aussi plus propre :-)

Voici le genre de chemin suivi pour la résolution du graphe de mise à jour d’un objet. Ici le cheminement est linéaire entre les objets intermédiaires, il devra être éprouvé sur un cheminement non linéaire (avec des objets manquants).
On part de l’objet 47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9 et on arrive à 672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549 (sur une base de liens plus réduite):

2013-12-06_u_47c1b111409c3a9ccb193b19c481b38715f9fc96da706d98c070ef9019890cb9_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85
2013-12-07_u_5376cfdb8b8d3e1c9c4832bb9d8cab0ba076bbf2d28ae53c8680088641d2aa85_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f
2013-12-10_u_e2e0fec866c726f3b284575435a81080f279e4afb46a7ba07edc39105f061a7f_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940
2013-12-11_u_9864740a3679164edfc130ba64658926470227e6a94056ce200a1157f729a940_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617
2013-12-12_u_aafc618df11870db1c833a6f0e31e8c4246645001b515040ee7d84cde135e617_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec
2013-12-13_u_1e45b26a70a8f19e3515d981100fc7a135b6b6e480bb170d41d2033120a02fec_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426
2013-12-24_u_0a2d68d69eca2bd3b83ea0306bc868c4ee684e8eb1665e9215263ea05a54c426_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d
2013-12-26_u_284ea4d9be9b206d73297bda696c77ef3389c47330e5b1d4c13dcf3ab3c5d20d_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5
2014-01-02_u_182b6e830ba6b21411695e9f99fddfddd12c0bee61fce41368c98e0c1254dab5_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9
2014-01-10_u_e304bf8534de8b6fba8a88bcbbcd520439527a8719579c1db2d3465465e463a9_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c
2014-01-13_u_ab46a8ed5c21a2d8ff9103088a8cdc07ea167eb577b3cc4ac0ec29b4388c4b0c_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0
2014-01-16_u_79ddbdd834c136e4616b71372de11d786b4730ea040bd732b1d91e17b10398b0_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962
2014-01-17_u_d6d226f89a247ef361ae1c0b0eb1c5383ea2ee7c1ee607255f84727b7da2c962_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd
2014-01-18_u_59b802549352603e2cc9d386788bbfe0336045cc841b96bdb707f87f4d9d0bbd_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9
2014-01-22_u_0131a0b7b758d24be4ecc6701fc942c8c73044f3fa85aa2e82fe42b5cfcf05d9_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2
2014-01-23_u_dd27f522db318f7fcf54852af861e656b184bd178c9718c7186efcedda49dba2_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e
2014-01-24_u_72ebbabbf4687106a70b5bba7f9c10ab096febd649f306660411f2cc6215981e_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b
2014-01-29_u_b364e1bf7181fa508032d5d26562350be6aadbb14949137e8d442bdc1912493b_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac
2014-01-30_u_cc1ec77ea4d137b7785c2de9dab0d818420f520f3502788aec56e1ca3cb081ac_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462
2014-01-31_u_c971f678bbfeba808c0f0b4f23f6d3f3bed21c098437ecfe54e0c46891696462_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb
2014-02-02_u_27ec39235f7f49f1a862ac303e54125cc2941455b832000957583130e08896eb_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249
2014-02-03_u_c92173177ed98cfbb651a76670b3e508834bbb217ac91b285c8ab20994f5b249_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883
2014-02-05_u_02ef13f3824b6412cbd38b9c33266a601b18a8812b84aff3fffb7647723b1883_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757
2014-02-06_u_60de6086e63a85db4a39ca06f1bccb966eaa3cb6d805889210a6cc63c5c59757_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba
2014-02-07_u_8334ed17bfe94db33690049ecae724b58e420478d62a902503bb95ab17e013ba_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164
2014-02-08_u_a6e76573b865ca90fb92b247c724474456db38023b6b9716b45ef41c6742e164_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4
2014-02-09_u_b8fb4e2a4fa515cc8ce6d130ab7cfcfa7138150d3117357514bfb5d868a726c4_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034
2014-02-10_u_b338bd787b97e6cd85ce9965b00d17a86d51255b87c8686d0444b6a87ea7f034_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9
2014-02-12_u_d4115805c826483a0a5f6988be4fcc4bac8b04d300cbb3c8f0244194777931f9_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d
2014-02-13_u_221ec95e1046265b03dc8800a7efed44df5e49b6db3b9f51048370009022698d_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683
2014-02-16_u_b80e64fc316768932fab063b35d47e3651eed66be7ca8756d2cb0bc82afbd683_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a
2014-02-17_u_76e3f1f5d64a221bf1a28964ae74f9752af3b26763b46523ea3b5e6a2a20511a_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f
2014-02-18_u_d1fd4dba3ec0ec7fda4898a16eac6593d10e80cb575511fd9cbe85ec214e487f_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7
2014-02-20_u_fbf7bcc5c27981b8953e2a8630f572774f6c16684ac8459bb240aeaca8bd8ff7_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15
2014-02-21_u_8badc8ba4a855acbbe58de48e5ac3fa4aeb3c3c69858401778adf771ed19be15_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63
2014-02-22_u_f05b4ac2d53b7287af3f15c3ab2e7da13fc3a80b37272cbbcfb400d287568f63_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72
2014-02-24_u_761625eb463d1e3930b80cf88d43157d778d10a23f3d0cba463c552322492b72_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf
2014-02-25_u_941752dc44b4a272bd7828724f7f3bd554fa1f3acca4dcb298f0ecf5428ecfbf_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5
2014-02-26_u_a3d7fcf4f1c88ce5350f065e16ce770cc6d6de6334e7fb6dd8403398c86ea1e5_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade
2014-02-27_u_1f3e1cec5ab724a701d7665f13003dc50765c3a066227d322d64804651de0ade_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e
2014-03-04_u_5154aa3a5ea8956db2279dbaa2d3944b5a87218202e838c2a4cfc27da172ed6e_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465
2014-03-26_u_0a65036105b001b926d1d0336aa4de5fde1d8a476f325f9832e524d914e7e465_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be
2014-03-28_u_5ac97a3a3c7c310b5afe24c210874c1b2ae69a80274755117cb7b8bb3b9299be_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40
2014-03-29_u_17bf49d31d9a2ab2d0d051ed1bb4c6a0acdfcad6da199fc86ebf47d8be284f40_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111
2014-04-01_u_9559ba4972cd3a4ada0d055101efdca7d6c0f942279c6bd05f23b2d0b118c111_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582
2014-04-02_u_a6968f3bb36ea04264f6e2314c661af3f4acda829a4515b73b701aea244b1582_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6
2014-04-03_u_f74debe6a24400c6dbbb4388eefac050d204b5073f643a3302c24fc15e7544c6_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7
2014-04-04_u_f6d07dd9f4e946bab71f1084d027f6b9cc16d7161e62cc4562e0bd94cce502d7_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94
2014-04-08_u_c8dbec0f85e19c313317f552e7acfaa2a23097150e592da400643d4c18884b94_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a
2014-04-09_u_28ae03264ae8505767aa5e3a3cbaf7d0a8a96c92236de5a10c14d694c498438a_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a
2014-04-10_u_33ae1c2aa592fb7ac7f95f03abfd5a6b46d4da48579a3153258890298336a01a_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c
2014-04-11_u_648f35156e67da0bdd9477020129c42e9ed07ac4f67e784f0f0cd931b1b4419c_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8
2014-04-12_u_907e5d86dec334e80a5e81d4e0b842bbeb0b491c7bba38699da25aa880ac49b8_672bad4d2c4bd4a5def227671a0eb22844dbb116d59d4cb948ecbaa4f6b0b549

Gestion des modules – IO et gros objets

Suite de l’article Gestion des modules.

L’exportation du traitement des IO dans des modules entraîne un autre problème avec les gros objets.

Les gros objets peuvent être visualisés dans le navigateur quoi qu’il arrive puisque la lecture du contenu d’un objet est faite par le navigateur et ce contenu est transmis sans traitement par le serveur web. Ce quelque soit la taille de l’objet.
Par contre, si un objet nécessite un traitement, comme le déchiffrement, alors cela ne marche plus de la même façon.

Le traitement d’un objet nécessite qu’il soit placé en mémoire de l’instance PHP en cours, avec toutes les restrictions et limites que l’on va rencontrer. Il n’est pas possible de travailler facilement comme on le ferait sur bash avec une série de ‘pipes’.

Ce problème va aussi se poser lors de la synchronisation d’un objet sur une serveur web externe, via le module IO HTTP. Avant de pouvoir l’écrire localement, via le module IO FileSystem par exemple, il devra tenir en mémoire.
Il est peut-être possible, dans le das d’échanges entre IO, de mettre en place des copies progressives d’objets pour soulager la mémoire. A voir…

Pour le déchiffrement et l’affichage, il est possible de créer une fonction spécifique. Pour le chiffrement, il va falloir travailler par blocs.

Gestion des modules

La gestion des modules existait au niveau de sylabe. Elle est ajoutée directement dans nebule en PHP. Ce qui permet de l’utiliser à la fois dans nebule et sylabe. Chaque programme peut utiliser ses propres modules.

La programmation orientée objet dans PHP permet de gérer plus facilement des modules puisque ce sont simplement des classes, une par module, qui respectent des interfaces précises et non des fonctions multiples par modules. Le mécanisme de gestion derrière consiste à recenser les classes qui respectent certains critères et les lister dans un tableau, pré-instanciées.

La pré-instanciation permet d’initialiser certains environnements comme un accès à une base de donnée par exemple.

Il y a deux niveau de gestion en fait.
Le premier se fait au niveau de nebule. L’instanciation de la classe nebule va rechercher tous les objets qui sont définis comme des modules, c’est à dire avec le bon type et qui sont liés uniquement par l’entité bachue. La recherche des modules se fait en mode strict, les autres entités sont ignorées sauf les entités marquées comme autorités locales.
Le deuxième niveau, toujours lors de l’instanciation de la classe nebule, va appeler une classe spécifique par catégorie de modules. Cette classe est dite classe de routage. Pour chaque catégorie de modules, la classe de routage va s’occuper de rechercher toutes les classes correspondants à des modules ayant la même interface.

La classe de routage respecte la même interface que les classes des modules concernés. Elle seule est définit et reconnu dans l’instance nebule. Et c’est elle qui, étant appelée, va transmettre les requêtes vers la classe, le module, la plus appropriée au traitement. Elle fait donc les rôles de découverte des modules et de routage vers ces modules. Comme la classe de routage partage la même interface, elle a le même comportement que celles-ci, ce qui facilite le développement.

Il existe actuellement deux classes de routages reconnues : io et social.
La classe communication a été fusionnée dans io n’existe plus.

Il y a cependant un problème. En intégrant les IO dans des modules à charger, on se coupe l’herbe sous les pieds puisque pour charger les modules il faut avoir des IO fonctionnels… alors que ces IO sont dans les modules que l’on veut charger…
Là, le bootstrap va nous aider puis qu’il contiendra la classe d’un module IO par défaut, les IO sur système de fichier (FileSystem). Lors du chargement de la librairie nebule en php, une nouvelle détection se fera mais sur les modules présents localement, c’est à dire sur le système de fichier.

Ce fonctionnement par défaut avec le bootstrap entraîne un autre problème. Puisque l’on va utiliser le module IO FileSystem par défaut, on ne prendra en compte que ce qui y est présent. Si la libraire charge par défaut un autre module IO, par exemple MYSQL, alors les mises à jours des objets, et donc des modules, ne seront pas écrit sur le système de fichiers, et donc ceux-ci ne seront pas mis à jour.
Il faut prévoir un mécanisme de mise à jour…

Avancement

L’implémentation du bootstrap en PHP orienté objet avance. Voici à quoi ça ressemble :

shot-2014-08-20_23-44-45

Voici les classes et interfaces actuellement utilisées :

  • class nebule
  • class Object
  • class Entity extends Object
  • class Localisation extends Object
  • class Link
  • interface ioInterface
  • class ioFileSystem implements ioInterface
  • class Metrology
  • interface CryptoInterface
  • class CryptoOpenssl implements CryptoInterface
  • interface CommunicationInterface
  • class Communication implements CommunicationInterface
  • class CommunicationHTTP implements CommunicationInterface
  • interface SocialInterface
  • class SocialStrict implements SocialInterface

Il est question de fusionner les classes Communication dans les IO. Les IO sur HTTP, SMTP et XMPP seraient des IO en lecture seule. Et surtout, ce serait des modules optionnels là où un module tel que ioFileSystem serait obligatoire. A moins que tout module d’IO ne soit valable et que l’instance ne fonctionne que avec des objets et liens sur un serveur HTTP ou XMPP autre, idée à creuser…

Avancement de la réimplémentation

La ré-implémentation de la librairie nebule php en orienté objet continue.

C’est plus long que prévu mais c’est intéressant. Cela oblige à refaire le tour des options et de leur pertinence avec le temps. C’est aussi l’occasion de revoir l’organisation de l’ensemble des fonctionnalités et de leurs places.

Je commence par le bootstrap puisque c’est l’implémentation la plus simple de nebule. Du coup, il ne change pas trop de forme mais il est réorganisé dans son fonctionnement. Un certain nombre de tests sont ajoutés pour vérifier le bon fonctionnement de l’ordinateur et de l’instance de nebule. Les entrées sorties sont vérifiées en lecture et écriture. Le bon fonctionnement de la cryptographie, qui se faisait jusque là dans sylabe, est aussi réalisée par le bootstrap. Le dysfonctionnement de certains tests critiques provoqueront le chargement de la page de bootstrap au lieu de l’application normale.

shot-2014-08-10_15-09-59

Le code correspondant, en cours de développement, est disponible ici :
http://stephane.nebule.fr/?mod=aff&obj=6ba665284be710117d2d2a2f81e8c9fe45d39e6fa270e54b7a515b63aa9eff3e

Lorsque le code sera intégré dans la librairie, les anciennes fonctions de la librairie procédurale seront ré-implémentées. Le code en orienté objet nécessite la connaissance de la programmation orientée objet, ce qui n’est pas à la portée de tout le monde puisque cela nécessite un temps de formation. Il faudra faire un guide d’utilisation de la librairie et de ses fonctions procédurales et orientées objet pour que n’importe qui puisse l’utiliser. Et puis, cela permettra aussi une transition facile pour le code de sylabe qui est en procédurale… et est assez volumineux pour moi à reprendre…

Les entités et le code

La remise en forme du code de nebule en php orienté objet amène son lot de questions.

Les entités de nebule

Les entités principales de nebule ont actuellement des noms mais ne sont reliées à leurs fonctions respectives que par leur usage dans le code.

Pour que ce soit plus clair dans le code, le nom est un peu trop hermétique. Je le remplace donc par un nom contenant directement le rôle. Ainsi, kronos par exemple s’appellera toujours kronos mais sera mémorisé dans une variable nommée time master. Et il en est ainsi pour toutes les entités qui ont un rôle dans nebule :

  • puppetmaster, ne change pas de nom, c’est l’entité qui chapeaute toutes les autres, le maître ;
  • cerberus, hérite du rôle et du nom security master, le maître de la sécurité ;
  • bachue, hérite du rôle et du nom code master, le maître du code ;
  • asabiyya, hérite du rôle et du nom directory master, le maître de l’annuaire ;
  • kronos, hérite du rôle et du nom time master, le maître du temps.

Les possibilités de gestion pour l’utilisateur

La sécurisation du code amène aussi des questions sur l’organisation de la gestion de certaines parties de la sécurité. Notamment, jusqu’où peut-on permettre l’ajout de droits à une entité normale ?

Cette entité peut vouloir utiliser des extensions externes au code d’origine tel que diffusé par bachue. Cela peux se faire en relation avec la définition d’autorités locales. L’ajout d’une traduction de l’interface en est un bon exemple. L’entité bachue peut aussi diffuser ou permettre la diffusion de plusieurs codes utilisables par une entité.

Plus on donne de droits à un utilisateur, plus il risque de se faire corrompre par un code malveillant. Il faut trouver un juste milieu. Le code et la gestion du bootstrap doit rester la plus saine possible dans tous les cas.

Redéfinition de puppetmaster

L’entité puppetmaster est celle qui contrôle toutes les autres, donc qui contrôle tout. C’est le point fort de la hiérarchie des entités, et aujourd’hui la moins vulnérable. Mais c’est aussi l’entité qui présente le plus grand risque pour l’ensemble puisqu’elle est unique et que sa compromission serait fatale à tout l’ensemble.

C’est le même problème que le système de certificats présente aujourd’hui. Quoique, c’est pire encore pour le système de certificats puisqu’il existe beaucoup d’autorités de certifications racines et que la compromission d’un seule casse la confiance de tout le système. Dans l’ensemble, ce système de certificats est bien fait à part cette horreur de monstre à têtes multiples. Un vrai trou conceptuel dans la sécurité. Les gouvernements et le grand banditisme l’ont déjà corrompu depuis quelque temps à leur avantage.

Pour l’entité puppetmaster, l’idée est de partir en sens inverse. Au lieu de divulguer cette entité à de multiples personnes et organismes dont l’intégrité et l’honnêteté sont loin d’être garanties, on ne diffuse qu’une partie du pouvoir de l’entité puppetmaster. Une personne seule ne doit pas pouvoir utiliser l’entité. Chaque lien doit être validé, et donc signé, par un corpus de plusieurs clés représentant l’entité. Par exemple, on peut partir sur dix sous-clés de l’entité, associées deux à deux.

On peut implémenter la vérification du quotas de sous-clés ayant signées un même lien. Mais cette façon de faire est un droit faible puisqu’il ne repose que sur du code. On peut, j’espère, trouver une implémentation mathématique permettant de mettre en place une signature unique combinaison de plusieurs clés.

Il faut aussi résoudre un problème organisationnel et non technique. En combien de parties découpe-t-on l’entité ?
Dans notre exemple dix sous-clés associées deux à deux, on a un pouvoir de la clé maître répartie en cinq couples de clés. Chaque clé d’un couple a le pouvoir du couple. Le couple ici fait référence au couple humain. Et le cinq peut faire référence à tout un tas de choses…
Est-ce la meilleur répartition ? Celle-ci doit-elle répondre à une organisation physique ? Philosophique ? Spirituelle ? Mystique ? etc…

PHP et programmation objet

La librairie de référence php est en cours de portage en programmation objet, ce qui est différent de la notion d’objet propre au projet nebule.

Je me base sur différents tutoriels :
http://fr.openclassrooms.com/informatique/cours/programmez-en-oriente-objet-en-php
http://jcrozier.developpez.com/tutoriels/web/php/programmation-orientee-objet/
http://stephaneey.developpez.com/tutoriel/php/php5_nouveautes/
http://alain-sahli.developpez.com/tutoriels/php/les-interfaces/
http://blog.xebia.fr/2011/07/18/les-principes-solid/

Les implémentations que je vais essayer de suivre pour leur côté éprouvé… et logique :
РLe mod̬le MVC.
– La notation PEAR.
РLe mod̬le Design by contract (DbC).
РLe mod̬le SOLID.

Le modèle MVC est assez logique, à tel point que c’est déjà quasiment la forme adoptée par le code de la librairie et de sylabe aujourd’hui.

Voici l’organisation du code pour l’instant :
– class nebule
– class Object extends nebule
– class Entity extends Object
– class Link extends nebule
– interface ioInterface
– class ioFileSystem implements ioInterface
– class Metrology

Exception à la notation PEAR, la classe nebule commence avec une minuscule et non une majuscule. C’est la seule.

Il y a des choses que je vais tout de suite bannir :
– On commence par les parent::quelquechose. Trop de risque de confusion et d’erreur.

A compléter…