Une nouvelle 020161127 version du bootstrap est mise en ligne.
Elle est en cours de test, il semble y avoir un petit problème pour accéder à l’application 0 dans certains cas. Cela concerne la partie de code qui vérifie l’activation des applications pour valider le changement d’application.
Le bootstrap sait maintenant gérer les applications activées. Ça se passe à deux niveaux.
L’activation d’une application se fait sur trois critères :
defaultApplication, elle est par défaut activée et non désactivable.L’entité maître du code bachue ne peut pas activer une application sauf à modifier les constantes dans le code.
Une application peut être activée/désactivée via l’application option, la seule application aujourd’hui en liste blanche. Il faut aller dans la partie des applications et il faut être connecté avec l’instance entité du serveur.
Le lien d’activation d’une application a la forme :
fe5ce3e9938247402722233e4698cda4adb44bb2e01aa0687e0e9ce893ea87b91f6e276b3839fed99f050168a0eb986354adc63abb3d7335ce5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
La désactivation est un lien de type x.
Le pré-chargement des applications par le bootstrap va permettre d’améliorer l’expérience utilisateur lors du premier chargement d’une application. Même si les applications n’ont pas encore été optimisées pour en profiter pleinement, c’est déjà fonctionnel et efficace.
Par contre, comme énoncé dans l’article pré-chargement des applications – indexation, certaines applications n’ont pas forcément un intérêt à être pré-chargées.
C’est le cas de l’application defolt qui se charge très vite et dont la page de pré-chargement n’apporte rien, voir casse un peu le principe de la page par défaut.
Et c’est aussi le cas de l’application upload qui charge vite mais qui peut à l’avenir permettre la synchronisation d’objets et de liens entre serveurs. Hors le passage par une page intermédiaire oblige le serveur distant à gérer le cookie de connexion avant de pouvoir envoyer des données.
La dernière version du bootstrap, qui va être bientôt publiée, reconnaît maintenant un lien pour désactiver le pré-chargement d’une application. Le comportement par défaut reste de pré-charger une application. Chaque application pourra, sur initiative du maître du code bachue ou d’une autorité locale, ne plus être pré-chargée.
Le lien de non pré-chargement a la forme :
fe5ce3e9938247402722233e4698cda4adb44bb2e01aa06879d019716a5335ee1f3bad59cbb9cc93132b0726129b26b52d6441a66c7c59a8de5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
De plus, le problème de dépassement de mémoire est résolu. Il vient d’une pré-allocation de mémoire de la fonction file_get_content qui se fait parfois sur la totalité de l’argument $maxlen alors que le contenu réel est dérisoire… et qui ne libère pas cette mémoire en fin de fonction.
Enfin, la métrologie a été aussi grandement renforcée. L’avenir dira si cela a un impact négligeable sur les performances ou pas. En fin de bootstrap, les logs contiennent une trace de la mémoire maximum utilisée ainsi que les objets et liens lus et vérifiés :
Nov 27 12:21:36 bachue bootstrap/81bd1a52600b: 0.64311790466309 Mp=9698504 Lr=2720+4 Lv=355+4 Or=361+0 Ov=8+0
Une nouvelle 020161123 version du bootstrap est mise en ligne, le différentiel :
bc3f2cf23e92fa55fca4f20307236d7653726f9f7ca4593589316f3b8bdb9a53
Comme c’est un différentiel, il faut importer les liens puis copier les objets, et enfin remplacer le bootstrap. La bibliothèque et toutes les applications ont été mises à jour.
L’application 0 semble avoir des problèmes sur certains serveurs. Les serveurs de test ne semblent par contre pas concernés. Le problème est en cours d’investigation…
Suite de l’article sur le Renforcement de la lecture des objets, type hash invalide et affichage.
Le renforcement de la lecture des objets et notamment la suppression sur empreinte invalide ou invérifiable entraîne un autre effet. Tout objet plus grand que la taille limite de lecture des contenus des objets, définit par l’option ioReadMaxData, est automatiquement supprimé lorsqu’on essaie de l’utiliser. Ce qui veut dire qu’il y a une valeur minimum à l’option ioReadMaxData pour ne pas empêcher le bon fonctionnement des applications.
Suite de l’article sur le Renforcement de la lecture des objets, et type hash invalide.
L’argument $permitTruncate ayant disparu, c’est aussi l’option displayUnverifiedObjects qui n’a plus de raison d’être. Les fonctions d’affichage qui auraient pu devoir afficher un objet trop gros pour le vérifier n’en verront plus dans tous les cas.
En échange, une nouvelle option permitCheckObjectHash est mise en place dans la bibliothèque nebule en PHP orienté objet.
Elle est utilisée dans la fonction _getUnprotectedContent(). Elle va activer la vérification de l’empreinte des objets lus, ou plutôt forcer la lecture de l’objet même si son empreinte est invalide ou non vérifiable. C’est le pendant de l’option permitCheckSignOnVerify ayant la même signification pour la vérification des liens. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à  true !
Dans l’article sur le Renforcement de la lecture des objets, il était question notamment de la possibilité de supprimer ou pas un objet dont on ne peut pas vérifier l’empreinte parce que le type de hash est soit inconnu soit non reconnu.
Lors de l’échec de la récupération du type de hash de l’objet, on essaye tout de suite, si l’option permitSynchronizeLinks est à true, de synchroniser rapidement les liens de l’objet. Puis on essaie de relire le type de hash de l’objet.
Une nouvelle option permitDeleteObjectOnUnknowHash vient d’être ajoutée. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à  true !
La nouvelle option est utilisée par la bibliothèque nebule en PHP en programmation orienté objet (library POO) par les fonctions checkConsistency() et _getUnprotectedContent() de la classe Object. La fonction _getProtectedContent() ne prend pas en compte cette option, elle se base uniquement sur _getUnprotectedContent() pour la lecture de l’objet protégé et de la clé de déchiffrement associée.
L’implémentation de l’option est un tout petit peu différent ce que l’on peut attendre. Lorsque l’on recherche le lien du type d’empreinte d’un objet (avec la pondération sociale), si aucun lien n’est trouvé ou si le nom de l’algorithme de prise d’empreinte n’est pas reconnu, alors il y a deux possibilités.
L’option permitDeleteObjectOnUnknowHash est à :
false. Dans ce cas les deux fonctions retournent tout de suite un résultat booléen négatif ou un contenu vide.true. Comme aucun algorithme n’est trouvé, on utilise l’algorithme définit par défaut et on continue le processus de vérification dans les deux fonctions. Si l’empreinte ne correspond pas avec cet algorithme, l’objet est supprimé. C’est une façon de donner une chance à un objet pour lequel les liens auraient été partiellement synchronisés.Dans la bibliothèque nebule en PHP en programmation procédurale (library PP), la lecture des objets se fait via les fonctions _o_ls1 et _o_lsx. La deuxième repose en fait sur la première. Et en début de fonction _o_ls1, un appel à la fonction _o_vr permet de vérifier le contenu de l’objet.
La fonction _o_vr ne prend en compte que les objets avec un hash fait avec l’algorithme par défaut, aujourd’hui sha256. L’option permitDeleteObjectOnUnknowHash n’est pas utilisée.
Dans les deux bibliothèques, si c’est l’objet avec d’identifiant 0, alors il est systématiquement supprimé.
Enfin, dans tous les cas, il ne faut surtout pas tenter de vérifier l’empreinte avec tous les algorithmes disponibles, cela reviendrait à permettre une attaque sur le plus faible de ceux-ci…
Dans la bibliothèque nebule en PHP orienté objet et dans certaines applications, un certain nombre de fonctions lisent le contenu des objets soit directement soit via la fonction getContent() de l’instance Object des objets. Toutes les lectures de contenus d’objets et de liens se font via la classe io de la bibliothèque et non directement par des fonctions de PHP de lecture de flux, de lecture directe. Les fonctions de la classe io ne font pas d’opérations cryptographiques, donc aucune vérification n’est possible à ce niveau.
Dans la bibliothèque se trouve aussi la fonction checkConsistency() pour vérifier le contenu d’un objet. Deux différences existent entre les deux fonction :
getContent() lit des données et vérifie si l’empreinte est bonne sauf si l’objet est trop grand. Si l’objet est trop grand, un argument $permitTruncate permet de ne pas rejeter le contenu de l’objet si il est trop grand. Pour les petits objets la vérification se fait dans tous les cas. La limite d’un objet petit ou grand est définie par l’option ioReadMaxData. Si l’empreinte ne correspond pas, le contenu n’est pas conservé et un contenu vide est renvoyé à la fonction appelante. La fonction checkConsistency() ne renvoie pas de données mais vérifie juste l’empreinte, le résultat booléen renvoyé et négatif ou positif.getContent() ne supprime pas un objet si l’empreinte n’est pas bonne. La fonction checkConsistency() vérifie l’empreinte et, si l’empreinte n’est pas bonne, supprime l’objet via une fonction de la classe io.Il est difficile de prendre une décision de suppression d’un objet parce que peut-être que l’algorithme de prise d’empreinte n’est pas reconnu par la machine sur laquelle tourne l’instance serveur. En cas d’absence de possibilité de vérification comme un type d’empreinte inconnu ou un objet trop grand, il faut renvoyer un contenu vide ou résultat négatif mais il ne faut pas supprimer l’objet. Quoique dans un mode paranoïaque, il faut peut-être prévoir de supprimer tout objet non vérifiable, à voir.
Pour commencer l’argument $permitTruncate n’a pas de raison d’être, il est contre productif parce qu’il affaibli l’ensemble du système. Il va être supprimé et les applications qui affichaient un objet avec un message comme quoi l’objet est trop gros vont afficher un message d’erreur sans le contenu.
Ensuite, la fonction getContent() fait appel à une fonction privée _getProtectedContent() pour lire le contenu d’un objet protégé. Elle va maintenant sous-traiter aussi la lecture des objets non protégés à une fonction privée _getUnprotectedContent(). Cette nouvelle fonction sera très similaire à la fonction checkConsistency() mais renverra un contenu complet ou vide au lieu d’un résultat booléen. Et bien sûr l’objet sera supprimé en cas d’empreinte invalide. Et la fonction _getProtectedContent() utilisera la fonction _getUnprotectedContent() pour la lecture de tous les objets accessibles non protégés.
La suppression de l’argument $permitTruncate va poser un gros problème pour l’affichage des gros objets. Ceux-ci via le navigateur peuvent être affiché dans certains cas parce que le navigateur les télécharge sur le serveur web pour les afficher au fur et à mesure. C’est le cas des vidéos non protégées. Une des options pour résoudre ce problème est peut-être d’utiliser le lien de type s jusque là inexploité par la bibliothèque…
Suite à l’implémentation du pré-chargement des applications dans le bootstrap, il y a quand même un effet de bord à attendre. Cette page peut poser problème pour les robots d’indexation des sites web de l’Internet pour les moteurs de recherche. Et c’est valable aussi pour les moteurs d’indexation de contenu en tout genre.
Deux parades sont possibles.
Si le robot garde le cookie de connexion, la redirection sur la page de pré chargement peut être complétée par un argument sans effet. Le robot verra ainsi un lien vers une page mais avec d’autres arguments, donc une page différente.
Si le robot ne garde pas le cookie de connexion, il faut prévoir une option ou un lien pour désactiver le pré chargement des applications, ou au moins de certaines.
Les deux solutions vont être mises en place plus tard…
Le serveur de l’entité maître du code bachue vient d’être mis à jour avec le nouveau bootstrap en php et tous les liens signés de celle-ci. On retrouve donc dedans les différentes applications.
Afin de faciliter l’installation, une archive prête à déployer de l’ensemble est disponible ici :
871d0e2a2dd623da97e0cc5ca313a56e1a55a410d2b5f9b69042379f4222f189
Cette archive contient déjà tous les objets et liens nécessaires au bon fonctionnement de l’ensemble. Cela évite la synchronisation (incomplète) du bootstrap lors de la première connexion.
Le bootstrap ayant fortement changé dans son fonctionnement interne, il n’est pas possible de simplement synchroniser les applications sur un serveur déjà en place.
Il faut pré-charger les objets de l’archive, pré-envoyer les liens de l’entité maître du code, et mettre en place le nouveau bootstrap…
Les guides d’installation ont été mis à jours :
Une nouvelle 020161102 version du bootstrap est mise en ligne :
6b99f2e3acba0c0c35052dd26ec2ca7f76b4a89485f57929d92e04f9180cb815
Quelques corrections esthétiques mais surtout une correction sur un gros bugg dans l’application 0 au moment de passer la main à une application appelée.
Dans les petites choses, on peut noter que le titre en deux lettres d’une application peut être maintenant personnalisable… dans la limite de deux lettres.
Comme les applications sont maintenant retrouvées via des objets de référence, j’ai fait en sorte de choisir la couleur de celles-ci.
Et l’application 0 de sélection d’une application ressemble à ça :
Jusque là , le bootstrap était le seul code à ne pas être vérifié. Il est le premier code à charger et si il lui est possible de calculer sa propre empreinte, il n’est pas possible de pouvoir vérifier et certifier celle-ci comme c’est le cas pour la bibliothèque. Et c’est logique, le bootstrap peut avoir été modifié pour ne plus se vérifier et dire que tout va bien.
On contournait le problème jusque là via les applications. Il fallait tenir à jour une liste des bootstrap supportés par l’application (ou vice versa en fait). Ça n’était pas pratique en fait.
Et puis les objets de références sont arrivés pour la bibliothèque et les applications.
Rien n’empêche de créer un objet de référence pour le bootstrap aussi, sur le même modèle que celui de la bibliothèque. Et c’est plus simple à mettre en place en fait. Il faudra juste ajouter le lien de référence pour toute nouvelle version du bootstrap et presque automatiquement toutes les applications le reconnaîtront juste en cherchant si il y a un lien de référence.
Dans le même temps, cette méthode à le mérite de permettre au bootstrap aussi de lui-même tester sa propre empreinte en regardant si il a bien le lien de référence. ce n’est pas infaillible, comme dit au début, mais c’est mieux que rien et c’est facile à implémenter.
Et ça marche bien. Une nouvelle version du bootstrap est diffusée avec cet ajout et quelques corrections mineures :
3a16374dc6ea7610c6ad464b3d627ae9409a78698fa18258d22946d2fd48d8f4
Une nouvelle version du code du bootstrap en php procédurale est diffusée :
6c902d8c29b965fde6d576ef04e5405c84b1353d01715c4fb96e561ba76e9114
Comme d’habitude, l’identifiant est sont empreinte sha256. C’est le seul code qui ne peut pas être signé.
Sauf problème de dernière minute lors des tests sur Internet, cette version est fonctionnelle et complète.
Il manque par contre les liens signés du maître du code bachue pour désigner la bibliothèque et les applications. Les différentes applications se lancent sauf sylabe qui coince sur un de ses modules. Lorsque l’ensemble sera à peut près stable, le tout sera mis en ligne.
Du fait des grands changements dans la gestion des arguments en ligne et des applications, les applications actuellement en ligne sur Internet ne sont plus compatibles avec le nouveau bootstrap.
Le travail sur le bootstrap progresse.
La modification du code pour rechercher la bibliothèque et les applications à partir des objets de référence est maintenant complète et fonctionnelle.
Les nouveaux arguments sont aussi fonctionnels. Il reste à vérifier que les applications utilisent bien ces nouveaux arguments.
La face erreur du bootstrap :
La face de sélection des applications, dite application 0 :
La face passagère de pré-chargement d’une application :
Le bootstrap utilise des arguments avec lesquels l’utilisateur peut interagir. Ce n’est pas nouveau et la liste s’allonge lentement mais inexorablement.
Les arguments permettent par exemple d’interrompre le démarrage du bootstrap pour afficher comme il travaille et si tout se passe bien. Ils permettent aussi de dire quel application on veut charger ou d’activer le mode de récupération.
L’allongement de la liste des arguments ajoute des possibilités mais introduit potentiellement des failles d’implémentation ou d’interprétation. Moins il y en a pour ce code critique, mieux c’est.
L’interaction avec le bootstrap étant de très bas niveau, proche d’une demande de contenu d’un objet ou de ses liens, il a été décidé de réduire au minimum la taille des arguments. Et comme il n’y a pas d’ambiguïté rien que sur la première lettre des arguments, les nouveaux arguments font maintenant une seule lettre.
Ce qui réduit pour la partie purement du ressort de nebule la liste des arguments à :
o : le contenu de l’objet. Opérateur dont la valeur désigne l’objet attendu.l : le contenu des liens de l’objet. Opérateur dont la valeur désigne l’objet.e : l’entité instance du serveur. Fichier contenant l’ID de l’entité.a : l’ID de référence de l’application à utiliser. Opérateur dont la valeur désigne l’objet de référence.b : arrêt du bootstrap. Commutateur.f : nettoyage complet de la session enregistrée. Commutateur.i : affichage réduit pour insertion à l’intérieur d’une autre page. Commutateur.r : mode de récupération. Commutateur.u : demande de chargement de la dernière version de la bibliothèque et de l’application. Commutateur.Un opérateur désigne une chaîne de texte de type clé=valeur. Un fichier désigne un fichier accessible directement sur le serveur sous ce nom. Un commutateur désigne une valeur présente comme argument d’une URL et qui suffit à activer un comportement défini.
Par exemple :
http://server.nebule.org/?o=6501352a9da77110e52e31338fd4801ahttp://server.nebule.org/?l=6501352a9da77110e52e31338fd4801ahttp://server.nebule.org/?bhttp://server.nebule.org/?a=0http://server.nebule.org/?f&rCe qui peut être récupéré via les arguments o, l et e le sont aussi directement via l’URL sans utiliser les arguments. Dans ce cas aucun pré-traitement n’est appliqué et applicable.
Par exemple :
http://server.nebule.org/o/6501352a9da77110e52e31338fd4801ahttp://server.nebule.org/l/6501352a9da77110e52e31338fd4801ahttp://server.nebule.org/eLe bootstrap retrouve l’application et la librairie nebule à utiliser en suivant des liens. Actuellement, il suit le graphe des mises à jours de l’application sélectionnée et celui de la librairie nebule.
Mais il est possible dans ce cas d’utiliser une autre méthode de suivi des liens pour retrouver la dernière version des applications et de la librairie.
La recherche par les graphes permet de suivre les liens de type u d’objets en objets jusqu’à arriver en bout de branche de l’arborescence des mises à jours. Évidement, il faut tenir compte des liens de type x de suppression de liens. Et il faut aussi que l’objet en bout de branche soit disponible sinon on remonte la branche en sens inverse…
La méthode est efficace mais elle est très longue a jouer.
Il est possible de faire plus simple pour un résultat identique dans notre cas.
La structure de recherche de la dernière version d’un objet a dans notre cas un cheminement complètement sous contrôle. Il n’est pas nécessaire de gérer une profondeur de recherche de plus de un niveau, même avec des liens de mise à jour. En ne fonctionnant plus que sur un seul niveau il est tout à fait possible de n’utiliser que des liens de type f depuis un objet de référence.
Et en plus il est possible de ne plus à devoir gérer les liens de suppression de liens. Un nouveau lien remplace automatiquement le précédent lien. Si il faut supprimer le lien de la dernière mise à jour, il suffit de rejouer à une date plus récente le lien de la version précédente.
Et ainsi il y a gain du nombre d’objets parcourus et gain de temps de traitement sur les quelques liens qui restent.
Cette méthode va être mis en place dès que possible dans le bootstrap.
Suite à la Reprise du bootstrap en programmation procédurale, le code à été en très grande partie revu.
La version en programmation procédurale est maintenant utilisée par défaut. La version en programmation orientée objet est laissée en l’état, elle n’est plus fonctionnelle.
Le nouveau bootstrap est pleinement fonctionnel à l’exception de la partie de premier chargement lorsque l’on installe une nouvelle instance de serveur.
Contrairement à avant, les applications et la librairie sont pré-chargés lors du premier lancement de l’application. Cela se passe dans une page dédiée qui une fois l’application en mémoire fait un rechargement de la page. Au rechargement, on est dans l’application. La page de pré-chargement peut être un peu longue comme dans la capture d’écran plus bas mais sur des machines récentes elle passera en moins d’une seconde.
Surtout, cette fonctionnalité qui paraît un peu cosmétique au premier abord va permettre de mieux gérer la sérialisation/désérialisation des différentes instances d’une application. C’est à dire qu’une fois le pré-chargement réalisé avec tous les calculs et parcours de liens effectués, le chargements suivants seront beaucoup plus rapides.
Le travail sur le pré-chargement a contraint la remise à plat des fonctions liées à l’instanciation et à la sérialisation/désérialisation des différentes classes des applications. Cela a été l’occasion de faire le ménage aussi; De fait, les applications ne sont plus compatibles avec les anciennes version du bootstrap.
Voici donc à quoi ressemble le bootstrap lorsqu’il est interrompu par l’utilisateur ou si il y a une erreur :
Page du bootstrap interrompu sur initiative de l’utilisateur.
Et enfin, voici à quoi ressemble la page de pré-chargement des applications :
Page de pré-chargement de l’application sylabe.
Un mode de récupération était déjà plus ou moins bien implémenté. Il a été repris à l’occasion de la ré-écriture du bootstrap et il a notamment été corrigé dans la librairie nebule.
L’activation de ce mode de récupération empêche simplement l’entité instance du serveur et l’entité par défaut de devenir autorités locales. C’est à dire que les options qui leur permettent de devenir autorités locales ne sont plus pris en compte.
Le fait d’être autorité locale permet de générer des liens, qui seront réellement reconnus, pour faire des mises à jours de la librairie et des applications au même titre que le maître du code bachue. C’est comme cela que l’on peut travailler le code signé sans avoir recours en permanence au maître du code. Et c’est aussi comme cela que l’on peut mettre en place sa propre application sans qu’elle soit signée du maître du code.
L’activation peut se faire via les arguments de l’URL en ajoutant rescue si l’option permitOnlineRescue est à true.
En cas de besoin, option modeRescue permet à true d’activer et de forcer le mode de récupération sans tenir compte de l’option permitOnlineRescue.
Depuis une semaine, le code du bootstrap en PHP procédural est en cours de refonte complète. La base utilisée était assez ancienne, elle datait d’avant le passage à la programmation orientée objet.
Ce travail correspond presque à une ré-écriture de zéro du bootstrap. L’inconvénient de cette version c’est qu’il sera pls difficile d’utiliser la librairie nebule sur autre chose qu’un système de fichier, par exemple une base de données. Mais le gros avantage c’est que la maintenance de la librairie est fortement simplifiée par rapport à sa version orientée objet. En effet le bootstrap nécessite quelques ajustements et notamment la désactivation de certaines fonctionnalitées. Ce serait trop compliqué de garder deux librairies orientées objets en parrallèle.
Cette nouvelle version introduit cependant quelques nouveautées :
La page du bootstrap est en cours de mise à jour pour suivre cette évolution.
C’est cette version qui sera désormés utilisé pour les nouvelles versions des applications.
Suite des articles sur l’Ajout d’émotions sur des objets et suites 1 2 3 4 5, et Liens d’émotions.
Les émotions sont maintenant fonctionnelles dans la version encore en cours de développement de la librairie des des applications comme sylabe ou klicty.
Une page dédiée à l’Iconographie dans nebule est créé afin de recenser les différents icônes utilisées par la partie affichage (display) de la librairie. La première rubrique concerne justement les icônes des émotions.
Voici à quoi ressemble les émotions sur un objet affiché dans sylabe avec plusieurs émotions de plusieurs entités :
