Catégorie : php

Intégration des groupes dans la librairie php

Suite à la définition des groupes, l’intégration a commencé dans la librairie php orienté objet.

L’intégration est profonde puisque les groupes sont gérés comme des objets spécifiques comme c’était déjà le cas pour les entités. Une classe dédiée ainsi que tout un tas de fonctions leurs sont dédiés et personnalisés.

Les applications sylabe et klicty vont intégrer progressivement les groupes, notamment dans un module adapté.

Dans le même temps, un groupe fermé étant uniquement constitué de liens d’une seule entité (et cela doit être vérifié), le filtre social est en cours de mise en place. Ainsi, il est possible de restreindre la prise en compte des liens suivant ces filtres sociaux :

  • self : liens de l’entité ;
  • strict : liens de l’entité et des entités autorités locales ;
  • all : toutes les entités, mais avec un classement par pondération des entités.

L’activation du filtre social et donc de la possibilité de le choisir dans le code à nécessité un revue de tout le code de la librairie et des applications. Il reste à vérifier les modules de sylabe.

Liens de propriétés d’un objet

Rien de vraiment nouveau pour ce début d’année 2016.

Via la librairie php, on pouvait récupérer une ou des propriétés d’un objet avec le contenu de ces propriétés, on peut maintenant récupérer juste le ou les liens correspondants. Ainsi il est possible d’extraire facilement d’autres informations sur ces propriétés comme la date ou l’entité créatrice…

Intégration d’une partie affichage dans la librairie PHP

Des corrections de buggs sont réalisés dans la librairie nebule en PHP ainsi que dans le bootstrap en fonction des progrès de klicty.

Pour faciliter le développement et la cohérence de l’affichage, la librairie nebule en PHP intègre maintenant une partie ‘display‘ dédiée à l’affichage de petites parties de pages comme par exemple un objet. La gestion globale de l’affichage reste du ressort des applications comme sylabe ou klicty.

Historique des liens générés

Il y avait dans la librairie nebule en php procédural une option permettant de copier au moment de leur écriture les nouveaux liens générés. C’est une forme d’historique qui vient en complément de la possibilité d’écriture des nouveaux liens signés dans les liens de l’entité signataire. Par défaut tout arrivait dans le fichier l/f qu’il fallait bien sûr penser à vider de temps en temps.

Mais cela n’avait pas été ré-implémenté. C’est maintenant fait dans la librairie en php orienté objet. L’option permitHistoryLinksSign permet d’activer cette fonctionnalité et est par défaut à false, soit désactivé.

C’est utile pour le développement puisqu’il suffit de récupérer les derniers liens des programmes en cours de développement pour les faire signer par une autorité de code (bachue). C’est plus facile que d’aller faire la pêche aux liens sur les différents objets concernés.

Projet klicty

Voici donc venir le projet klicty. C’est un dérivé de sylabe mais en plus spécialisé et donc plus léger aussi. En attendant qu’il ai sont propre blog, voici donc quelques captures. Globalement, il va permettre le partage de fichiers sur Internet, mais bien sûr le moteur c’est nebule…

20151031 klicty_-_hôte_bachue_-_2015-11-01_00.41.11Écran d’accueil.

Continuer la lecture de Projet klicty

Page par défaut du bootstrap

Le bootstrap évolue un peu dans la présentation de sa page par défaut :

20151022 nebule_bootstrap_-_2015-10-22_23.47.17

Une nouvelle application klicty s’ajoute à sylabe, c’est pour plus tard…

Mais sur un serveur, il n’y aura sûrement qu’une seule application, et elle sera utilisée par défaut plutôt que de passer par cette page du bootstrap.

Liens marqués entre le puppetmaster et les autres entités

Il y a quelques jours, le puppetmaster a été réveillé pour générer de nouveaux liens. De nouveaux objets de nebule sont maintenant reconnus comme des objets à usage réservé :

  • nebule/objet/entite/maitre/securite
  • nebule/objet/entite/maitre/code
  • nebule/objet/entite/maitre/annuaire
  • nebule/objet/entite/maitre/temps

Et il permettent de désigner via un lien de type f les différentes entités qui ont les rôles correspondants.

Le code de la librairie nebule en php et le bootstrap s’en servent désormais pour retrouver les entités avec ces rôles.

CF : sylabe – Avancement

Dissimulation de liens, multi-entités et anonymat

La dissimulation de lien tel que prévu dans nebule n’est que la première partie permettant l’anonymisation des échanges entre entités.

Voir les articles précédents :
РLiaison secr̬te et suite ;
– Nouvelle version v1.2, Anonymisation de lien et correction du registre ;
РLien de type c, pr̩cisions ;
РEntit̩s multiples, gestion, relations et anonymat et Entit̩ multiples ;
– Nébuleuse sociétale et confiance – Chiffrement par défaut

Cette dissimulation d’un lien se fait avec un lien de type c. On a bien sûr dans le registre du lien visible l’entité qui génère ce lien, l’entité signataire. Et on a l’entité destinataire qui peut déchiffrer ce lien dissimulé et en extraire le vrai lien. Et comme dans la version publique de ce lien on a à la fois l’entité source et l’entité destinataire qui sont visibles, il n’y a pas d’anonymat. Ce type de lien permet juste de dissimuler l’usage d’un objet.

2015.06.27 lien c

Un lien dissimulé ne peut pas contenir un autre lien dissimulé. On interdit donc les multi-niveaux de liens dissimulés qui seraient un véritable calvaire à traiter.

Un lien peut être dissimulé pour soi-même. C’est à dire que l’entité signataire est aussi l’entité destinataire.

Si un lien doit être dissimulé pour plusieurs destinataires, il faut générer un lien pour chaque destinataire. La seule façon de réduire le nombre de liens pour un grand nombre de destinataires est d’utiliser la notion de groupe disposant de son propre bi-clé. Ce type de groupe est pour l’instant purement théorique.

Ce maintien comme public des entités sources et destinataires est une nécessité au niveau du lien, c’est une des bases de la confiance dans les liens. Pour que le lien puisse être validé et accepté par une entité ou retransmit par un relais, l’identification des entités est incontournable. Et donc avec l’identification nous avons aussi l’imputabilité et la non répudiation.

Si on veut assurer de l’anonymat pour les entités, puisque l’on ne peut pas travailler au niveau du lien, il faut travailler au niveau de l’entitié. On va dans ce cas travailler sur la notion de déception, c’est à dire faire apparaître des entités pour ce qu’elles ne sont pas ou tromper sur la nature des entités.
L’idée retenu consiste, pour chaque entité qui souhaite anonymiser ses échanges avec une autre entité, à générer une entité esclave avec laquelle elle n’a aucun lien. Ou plutôt, le lien d’entité maîtresse à entité esclave est un lien dissimulé pour l’entité maîtresse uniquement. Ici, personne à par l’entité maîtresse ne peut affirmer juste sur les liens que l’entité esclave lui est reliée.
Lorsque l’on veut échanger de façon anonyme, on transmet à l’entité destinataire l’identifiant de l’entité esclave, et vice versa. Cette transmission doit bien sûr être faîte par un autre moyen de communication ou au pire par un seul lien dissimulé.

L’anonymisation complète est donc la combinaison des liens de dissimulation de liens et d’une capacité multi-entités des programmes.

La dissimulation est en cours d’implémentation dans sylabe en programmation php orienté objet. Mais le plus gros du travail sera à faire dans la librairie nebule puisque c’est elle qui manipulera les liens et présentera ceux-ci à l’application, c’est à dire sylabe, dans une forme exploitable. L’application n’a pas à se soucier de savoir si le lien est dissimulé, elle peut le lire ou elle ne peut pas. Tout au plus peut-elle afficher qu’un lien est dissimulé pour information de l’utilisateur.
La capacité multi-entités de sylabe est maintenant beaucoup plus facile à gérer en programmation php orienté objet. Mais il reste à implémenter la génération des entités esclaves avec dissimulation de leur entité maîtresse.

Une autre dimension n’est pas prise en compte ici, c’est le trafic entre les serveurs pour les échanges d’informations. Il faudra faire attention à la remontée possible aux entités maîtresses par leurs échanges.

Enfin, pour terminer, aujourd’hui c’est la course au chiffrement par défaut de tous les échanges pour tout un tas de programmes et services sur Internet. Ce chiffrement par défaut est bon pour l’utilisateur en général. Et il masque dans la masse les échanges pour qui la confidentialité est critique. Ainsi il ne suffit plus d’écouter le trafic chiffré pour retrouver ses ennemis.
Mais cette logique est perverse. Le chiffrement par défaut est une aberration, un remède de cheval posé en urgence faut de mieux. Nous avons besoin d’échanger aussi des choses publiquement, comme sur un forum ou dans la presse. Nous ne devrions pas avoir des outils de communication tout chiffré et d’autres tout public, chaque outil devrait permettre les deux et clairement indiqué ce qui est protégé de ce qui ne l’est pas…

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);
}

Entités multiples

Dans la suite des réflexions sur Entités multiples, gestion, relations et anonymat, le développement de la librairie nebule en php continue en tenant compte de cette possibilité.

En gérant le mot de passe d’une entité dans l’objet (php) de cette entité, on peut avoir plusieurs entités déverrouillées à un instant donné. Et comme plusieurs entités sont potentiellement déverrouillées, lorsque l’on consulte un objet chiffré, il ne faut plus seulement regarder si l’entité courante est déverrouillée et donc peut le lire, mais il faut regarder dans tous les destinataires si une des entité n’est pas déverrouillée aussi. Une seule suffit pour déchiffrer l’objet et afficher son contenu.

Il faut cependant faire attention à ce que l’entité courante ait bien l’accès à l’objet chiffré avant de permettre son utilisation parce que cela dévoilerait immédiatement le lien de parenté entre les deux entités. Il est imaginable de basculer immédiatement d’entité courante sur une action de ce genre.

Si on souhaite une bascule complète sur une entité esclave sans interférence d’autres entités, il suffit de vider le mot de passe de tous les objets (php) des entités que l’on ne souhaite plus voir. Cela inclut aussi l’ancienne entité courante qui peut avoir été préalablement sauvegardée avec sont mot de passe pour une restauration ultérieure.

Une des applications de cette capacité multi-entité, c’est le cumule d’entité lors d’un Changement d’identifiant d’entité. Il est possible, le temps de migrer les liens, de pouvoir continuer à consulter les objets de l’ancienne entité tout en utilisant la nouvelle entité.

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…

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

Afin de tester les nouvelles fonctions avec sylabe, et pour pouvoir aussi reprendre le développement de ce dernier, les anciennes fonctions de la librairie en php procédural sont réinjectées dans la librairie en php orienté objet. Ainsi sylabe fonctionne et les anciennes fonctions procédurales vont pouvoir être progressivement reprogrammées pour faire appel aux nouvelles fonctions orienté objet…

Le code n’est pas encore diffusé puisqu’il est assez ‘sale’. Mais ça viendra…

Mémorisation de liens et accélération des traitements

Par défaut, à chaque chargement d’un objet pour traitement ou pour son affichage, chaque liens sont lus et vérifiés, puis relus et revérifiés. Parce que cette vérification implique des algorithmes cryptographiques de prise d’empreinte et des algorithmes cryptographiques asymétrique (à clés privées), le traitement cumulé de chaque vérifications devient vite une quantité non négligeable. Bref, le temps de calcul se ressent dans le traitement.

Il est possible d’accélérer ce fonctionnement avec la mémorisation des vérifications déjà faites.

Pour commencer, on peut considérer en première approximation que la plus grande partie du temps de traitement est imputable à la cryptographie asymétrique. On considère donc par défaut que les autres traitements sont, temporellement, quantités négligeables. cette approximation est vérifiée en pratique dans sylabe lorsque l’on désactive la vérification des signatures.

Pour des raisons de sécurité, les liens qui ont été vérifiés, et que l’on souhaite mémoriser, doivent être mémorisés en intégralité. Il ne faut pas garder uniquement la signature du lien. Il est préférable de conserver l’intégralité du lien. Tout au plus peut-on supprimer le champs signature. Ces liens pré-vérifiés doivent être conservés en lieu sûr, non modifiable par une autre entité ou un autre processus.
Dans ce cas, la vérification d’un lien va commencer par le parcours des liens déjà vérifiés, puis en dernier recours à vérifier le lien. Au delà d’un certain nombre de liens mémorisés, il est possible que le bénéfice de la mémorisation soit négatif vis-à-vis de la vérification direct des signatures des liens. Il faudra montrer expérimentalement l’ordre de grandeur de la table des liens mémorisés. Qui dit table de mémorisation limité dit aussi gestion de la quantité de liens mémorisés et donc du remplacement de certains liens par d’autres. Ce remplacement peut se faire en boucle, sans calcul, ou au contraire en tenant compte du temps de dernier usage des liens mémorisés. Bref, il y a du travail d’optimisation en perspective.

Comme on l’a vu avec une table de mémorisation limitée, le temps de mémorisation des liens peut être variable. De même, une autre période de rétention peut exister. La table de mémorisation peut n’être valable que pour le temps de chargement d’une page (web). Ou au contraire la table de mémorisation peut être valable le temps de la session, c’est à dire tout le temps ou l’entité est déverrouillée. Dans le cas de navigations sur sylabe, et en étant non-déverrouillée, la mémorisation peut être liée à la session php, et donc expirer avec celle-ci.

Imaginons maintenant un peu le futur. Imaginons que chaque entité, chaque humain dispose de sa clé privée en permanence dans un périphérique, ou plutôt une prothèse. Empactée dans du matériel, la clé privée serait beaucoup mieux protégée. De fait, corrompre la table de mémorisation des liens vérifiés deviendra un moyen plus facile pour modifier le comportement d’une entité. Il doit donc être maintenu la possibilité de fonctionner en mode paranoïaque en vérifiant à chaque utilisation les liens.

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

Interface par défaut de serveurs

Une nouvelle interface est terminée, elle concerne les serveurs en php. Cette interface s’appelle nServ et ressemble à ça :

nServ_-_2014-09-21_15.23.20

Elle peut être simplement définit comme étant l’application par défaut en utilisant le bootstrap classique. Elle peut aussi, si on n’implémente pas php, et donc pas de bootstrap, être présente comme fichier par défaut index.html avec les informations écrites directement dans la page et non générées automatiquement. Dans ces informations, on retrouve le nom public de l’entité, son identifiant et quelques informations sur nServ et sa licence.

A noter que le nom est ici celui de mon entité, mais se sera à terme normalement celui d’une entité de serveur…

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.

IO HTTP et performances dans PHP

Pour les besoins du module des IO sur HTTP, j’ai réalisé quelques tests afin de déterminer la meilleur méthode pour vérifier la présence d’un dossier ou d’un fichier sur un serveur web via HTTP.

La méthode la plus simple consiste à appeler l’URL de ce que l’on veut avec l’instruction file_get_contents.
C’est très simple mais très lent puisque tout le contenu est téléchargé alors que l’on ne souhaite que l’entête de la réponse du serveur. En fait, on a juste besoin de la première ligne de la réponse pour connaître le code de réponse du serveur, 200 si un fichier est disponible. 404 si le fichier n’existe pas. 403 si le fichier n’est pas accessible pour cause de restriction.
A noter que cette instruction et d’autres comme fopen nécessitent d’autoriser explicitement l’ouverture des URL avec allow_url_fopen=On et allow_url_include=On. Ces options sont nécessaires au bon fonctionnement du bootstrap, cela n’introduit donc pas de configuration supplémentaire.

La seconde méthode consiste à demander l’entête (header) via l’instruction PHP correspondante, get_headers.
Sauf que ce n’est pas mieux puisque le contenu est malgré tout téléchargé même si au final on n’extrait que l’entête.

Une autre méthode consiste à utiliser la librairie CURL dans PHP. Cette librairie est spécialisée dans les manipulations des URL, mais cela oblige à l’installer, ce qui n’est pas forcément la meilleur solution.
Par contre, en terme de performance, c’est d’un autre niveau. On peut raisonnablement savoir si un gros fichier est présent sur le serveur sans avoir de temps de latence démesuré. Au moins pour ces performances, cela peut valoir le coût d’installer cette librairie.

Enfin, une dernière solution consiste à générer soit-même la requête à transmettre au serveur et d’analyse la réponse. Cela peut être fait avec l’instruction fsockopen. Mais il faut tout faire, générer la requête, la transmettre, recevoir la réponse et la traiter.
La requête doit être du type HEAD pour n’avoir que l’entête.
Après avoir fait divers tests, cette dernière solution semble la plus rapide.

Voir les temps de réponses pour savoir si le dossier l est présent sur le serveur web local (CF code en annexe) :

 file_get_contents
 HTTP/1.1 200 OK
 2.0584919452667s

 get_headers
 HTTP/1.1 200 OK
 1.8262121677399s

 curl
 200
 0.006443977355957s

 fsockopen
 200
 0.0010509490966797s

Le dossier en question contient 24000 fichiers.
Il est clair de fsockopen est la solution la plus performante. C’est celle qui sera utilisée.

Je ne traite pas le cas des renvois type 301 puisqu’il n’est pas prévu pour l’instant dans la librairie nebule de suivre ces renvois.

Continuer la lecture de IO HTTP et performances dans PHP

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…