bootstrap – Mise en ligne

Une nouvelle 020170508 version du bootstrap est mise en ligne.

Le développement continue sur l’application option avec sa séparation de la gestion des autorités globales et locales.

La réflexion est toujours en cours sur l’avenir des autorités globales mais les autorités locales vont sûrement être scindées en plusieurs rôles sous des dénominations différentes.

Pas d’installateur complet pour cette fois, les deux applications sylabe et klicty sont mise à jour.

Le code est disponible ici :

94373583d31df5241fdf19de50be0e65fb6f65387188866818aebadd5a7217c5

Modification de l’ordre de prise en compte des propriétés d’un objet

Je reprends progressivement le développement de nebule pour corriger le bugg de klicty et améliorer dans sylabe le module correspondant.
Et je tombe sur un problème non dans l’implémentation mais dans la façon dont on prend en compte les propriétés d’un objet, ou plutôt l’ordre de prise en compte lorsque cela est fait plusieurs fois. C’est à dire, quel propriété retient-on en priorité lorsqu’il y a plusieurs liens d’un objet vers plusieurs propriétés.
Le problème n’a pas une solution difficile en soi mais le fait qu’il concerne une brique importante de nebule me freine à le modifier sans plus de réflexion. Les implications que cela engendre peuvent être très importantes dans pleins d’endroits du code de la bibliothèque de nebule et des applications. Continuer la lecture de Modification de l’ordre de prise en compte des propriétés d’un objet

bootstrap – Mise en ligne

Une nouvelle 020161212 version du bootstrap est mise en ligne.

Cette version introduit les entités de recouvrement. Le fonctionnement est complet et tel que décrit dans les articles Entités de recouvrement, implémentation et configuration.

Le développement continue sur l’application option afin de la rendre plus facile à utiliser et pour ajouter de nouvelles possibilités. Il intègre la gestion des entités de recouvrement mais un bugg résiduel. Il n’est pas possible de définir une entité de recouvrement si l’entité instance de serveur n’est pas autorité locale et entité de recouvrement. Ce sera corrigé pour la prochaine version, il suffira que l’entité instance de serveur soit uniquement autorité locale.
Les prochaines versions de l’application option et de la bibliothèque feront la distinction entre autorités locales et globales. La notion d’administrateur pourrait apparaître en plus.

Le code est disponible ici :

ae5aa99c9ab66d37a43a1611c69a0aca2ff746b44ec68caf2f6f6bc024011f4f

Entités de recouvrement – implémentation

Dans le précédent article sur les Entités de recouvrement qui date de plus de 6 mois, il était question de l’implémentation du mécanisme dans le code. Jusque là la liste des entités de recouvrement était renvoyée vide.
Ce mécanisme peut être une contrainte légale dans certains pays mais ce peut être aussi un moyen d’assurer plus sereinement la disponibilité des données sans remettre en question significativement la confidentialité de celles-ci. Sa portée est strictement local et ne doit pas devenir un comportement global sous peine de rompre la confiance dans l’ensemble du code de nebule.

La prochaine version de la bibliothèque nebule en PHP intègre le code nécessaire à la détection des entités marquées localement comme entités de recouvrement et le code qui se charge de dupliquer la protection des objets pour ces entités.

La définition des entités de recouvrement est purement locale et est attachée à l’entité instance locale. La détection d’entité de recouvrement se fait sur un lien de type f entre chaque entité définie comme entité de recouvrement et l’entité instance locale. Le champ méta du lien est l’objet de référence contenant nebule/objet/entite/recouvrement. Seuls les liens des autorités strictement locales sont pris en compte, c’est à dire à l’exception du puppetmaster, du maître de la sécurité et du maître du code.

La duplication de la protection se fait au niveau de la fonction (unique) de protection d’un objet setProtected(). Afin d’éviter la suppression du partage de protection avec une entité de recouvrement, la fonction cancelShareProtectionTo() ne supprime pas ce partage si l’entité est dans la liste des entités de recouvrement.
Afin de ne pas perturber l’utilisateur, les applications affichent tous les partages de protection mais n’affichent pas le bouton correspondant pour ces entités de recouvrement.

Les applications option, sylabe et klicty permettaient déjà l’affichage des entités de recouvrement même si elle était vide. Ces affichages ont été améliorés afin d’afficher en plus l’entité autorité locale qui a activé l’entité comme entité de recouvrement. Le but est d’avoir un mécanisme qui peut être contraignant et indiscret mais dont le fonctionnement doit être ouvert et loyal pour maintenir la confiance de l’utilisateur.
L’application option est maintenant le centre de gestion des entités de recouvrement. Il est possible, lorsque l’on déverrouille l’entité instance de serveur, d’ajouter ou de retirer des entités à la liste. Les autres entités ne peuvent faire que de l’affichage. Si un lien est généré par une autre entité, il est ignoré.

bootstrap – Mise en ligne

Une nouvelle 020161129 version du bootstrap est mise en ligne.

Cette version corrige les problèmes d’accès à l’application 0.

Le développement continue sur l’application option afin de la rendre plus facile à utiliser et pour ajouter de nouvelles possibilités.

Les icônes des émotions sont de retour dans sylabe et klicty.

Le code est disponible ici :

a9cd70c397af6c02ffc7cf964a89beaed941293cb8fca6ae80947161f7bc1465

bootstrap – Mise en ligne

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.

bootstrap – Désactivation des applications par défaut

Le bootstrap sait maintenant gérer les applications activées. Ça se passe à deux niveaux.

  1. L’application 0 de sélection des applications n’affiche que les applications activées.
  2. Le moteur de sélection de l’application à afficher ne permet pas de sélectionner une application si elle n’est pas activée.

L’activation d’une application se fait sur trois critères :

  1. C’est l’application par défaut définit par l’option defaultApplication, elle est par défaut activée et non désactivable.
  2. C’est une des applications en liste blanche. La liste blanche est une constante définie dans le bootstrap et dans la bibliothèque. Elleet non désactivable.
  3. L’entité instance du serveur a activé explicitement l’application par un lien.

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.

020161127 shot-2016-11-27_18-52-59

Le lien d’activation d’une application a la forme :

  • action : f
  • source : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
  • cible : objet de référence d’activation = e0e9ce893ea87b91f6e276b3839fed99f050168a0eb986354adc63abb3d7335c
  • méta : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687

La désactivation est un lien de type x.

bootstrap – Avec ou sans pré-chargement des applications

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 :

  • action : f
  • source : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
  • cible : objet de référence de non pré-chargement = 9d019716a5335ee1f3bad59cbb9cc93132b0726129b26b52d6441a66c7c59a8d
  • méta : objet de référence de l’application, par exemple = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687

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

bootstrap – Mise en ligne

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…

Renforcement de la lecture des objets – taille limite

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.

Renforcement de la lecture des objets

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 :

  1. La 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.
  2. La fonction 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…

bootstrap – pré-chargement des applications – indexation

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…

Mise en ligne d’un paquet complet

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 :

bootstrap – Mise en ligne

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 :

5e393f797adf5da6318afcde85027c454f73565fcaaff07f475e04ba5351aa62

Signature du bootstrap

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

Avancement du bootstrap

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.

Avancement sur le 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 :

020161030 bootstrap_-_2016-10-30_19.22.10

La face de sélection des applications, dite application 0 :

020161030 bootstrap_-_2016-10-30_19.33.18

La face passagère de pré-chargement d’une application :

020161030 bootstrap_-_2016-10-30_20.05.05

Changement des arguments en ligne du bootstrap

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=6501352a9da77110e52e31338fd4801a
  • http://server.nebule.org/?l=6501352a9da77110e52e31338fd4801a
  • http://server.nebule.org/?b
  • http://server.nebule.org/?a=0
  • http://server.nebule.org/?f&r

Ce 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/6501352a9da77110e52e31338fd4801a
  • http://server.nebule.org/l/6501352a9da77110e52e31338fd4801a
  • http://server.nebule.org/e

Objet de référence contre suivi du graphe des mises à jours

Le 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.