Avancement

Hier soir, j’ai appliqué les modifications d’arborescence proposées dans le précédent post Arborescence sur serveur web.

Tous les serveurs web qui héberge une copie de sylabe ont été modifiés en conséquence, c’est à dire :

Ces sites sont un peu lents dans le traitement de sylabe parce que la validité des liens est vérifiée systématiquement pendant le traitement, y compris la signature… On s’assure ainsi que les liens sur le serveur sont valides, mais c’est beaucoup plus lent. Ce comportement ne sera pas forcément celui par défaut plus tard.

Arborescence sur serveur web

L’implémentation de référence de nebule en bash utilise cette arborescence pour son fonctionnement :

  • pub
    • o
    • l
  • priv
    • o
    • l
  • tmp

On trouve notamment dans pub et priv un fichier e contenant l’identifiant de l’objet entité, la clé publique pour le premier et la clé secrète pour le seconde.

Dans pub, on peut encore trouver sur certaines machines gnav.php et un répertoire g. C’est la page de tracé du graphe d’un objet. Cette page php est vouée à disparaître sous cette forme.

Le contenu du répertoire pub avait été volontairement séparé, c’est à dire les répertoires o et l en dessous, des scripts et autres fichiers bash, clés RSA, etc… Est apparu avec le temps les dossiers priv et tmp pour manipuler les objets soit qui ne devaient pas être diffusés soit les fichiers temporaires. Et le répertoire pub à rapidement servit à stocker aussi de nouvelles pages web en php comme gnav.php et webcli.php . Ce répertoire devenait donc directement public, ce pour quoi il est fait dès le début en fait…

Lors de la mise en place de sylabe, j’ai conservé cette arborescence par défaut. Mais elle pose problème.
Les objets et liens sont téléchargés sur des url du type http://site.net/o/ ou http://site.net/l/ . Or le serveur web utilise par défaut le dossier parent pour l’affichage des pages. Cela nécessite de faire le lien entre le pseudo dossier o et son réel emplacement en pub/o . En fonction du système d’exploitation et du logiciel serveur web, la manière de contourner ce problème est différente. Ce n’est pas vraiment optimal.

Il faut cependant pouvoir faire cohabiter simultanément les scripts bash et les pages php, voir peut-être d’autres choses par la suite.

Il y a une solution, remettre le dossier pub comme répertoire par défaut dans le serveur web, c’est à dire l’arborescence racine. Les scripts bash peuvent rester dans le répertoire parent sans entrer en conflit avec les pages php dans pub, tout en exploitant la même base d’objets et de liens. En bash, les objets sont dans pub/o alors que en php ils sont dans o tout simplement.

Et comment dans sylabe va-t-on gérer les fichiers temporaires et fichiers à ne pas partager ?
Cela peut être fait de deux façons. Soit on crée un sous dossier avec des restrictions via un fichier .htaccess. Cette méthode à inconvénient de se restreindre à un seul type de serveur web. Et plus grave, tous les objets privés de toutes les entités connectées sont ainsi mélangés… Soit on fait du déchiffrement à la volée et du stockage de petits objets dans la session php.
Les fichiers temporaires peuvent eux être mélangés tant qu’ils ne sont pas écrasés ou réutilisés entre deux sessions différentes. Dans ce cas il faut peut-être prévoir un sous dossier tmp.

Avancement

Le code n’est pas publié ce soir puisque cela n’a pas encore d’intérêt, mais la fonction _l_lsx sait maintenant supprimer les liens qui ont un lien similaire mais en x, ainsi que les liens x aussi. Ainsi, a notion de suppression de lien devient fonctionnelle dans sylabe.

Par contre, seuls les liens x générés par la même entité signataire sont pris en compte. Il faudra ajouter une sorte de pondération social pour accepter ou non la suppression d’un lien par une entité tierce. C’est à dire gérer les relations de confiances…

Par la suite, on va pouvoir gérer les liens de type u. Et en particulier la mise à jour de code php. On doit pour cela savoir suivre les mises à jours de ces codes, mais aussi de tenir compte de suppressions de ces mises à jours, en cas de problème…

Avancement

Aujourd’hui, correction de quelques petits buggs sur le code de index.php, pas d’évolution.

Dans la vue obj, les objets sont maintenant affichés dans l’ordre alphabétique. C’est un peu plus facile pour retrouver un objet… Mais vue la quantité d’objets, ce n’est certainement pas la vue la plus intéressante. Côté performance, la lecture des objets ainsi que leur réorganisation prend environ une seconde alors que leur affichage reste de l’ordre de la minute pour environ 9000 objets. Il faudra peut-être supprimer l’affichage du type et du nom de chaque objet pour revenir à des temps plus raisonnable… CF http://zulu.nebule.fr/sylabe.php?mod=obj

Avancement

Les images des logos nebule et sylabe qui apparaissent dans les interfaces web ont été encodées pour être intégrées directement dans la page html. Cette méthode évite de traîner la copie de ces images vers de nouveaux sites web. Tout est dans un seul fichier php, ou trois dans le cas de sylabe.
Cependant, ce n’est pas tout à fait neutre pour les performances. Ces images qui auparavant se retrouvaient tout de suite dans le cache du navigateur, et donc n’étaient plus téléchargées par la suite, sont maintenant systématiquement re-téléchargées avec la page html.
Il est prévu pour palier ce petit problème de nébuliser plus tard ces images et simplement d’y faire référence comme objet dans le code php. On résoudra ainsi à la fois le problème de téléchargement multiple et le problème des fichiers images annexes. Il en sera de même pour les différentes petites icônes que l’on trouve un peu partout dans sylabe

Un autre changement a été mis en place. Un changement pas très visible mais assez important.
La page par défaut d’un site web nebule/sylabe référence en fait le fichier index.php . Au lieu de simplement afficher la page par défaut de nebule, cette page commence enfin à devenir une page de démarrage à par entière. Elle peut en effet créer tous les dossiers et fichiers nécessaires à nebule et donc aussi à sylabe. Une partie du code sait télécharger l’entité bachue qui va référencer les programmes de base. Ce n’est que le début, à terme il suffira de poser ce fichier index.php spécifique à nebule pour avoir instantanément la possibilité de mettre en place sylabe ou d’autres interfaces.
L’entité bachue est destinée à gérer la diffusion des différentes implémentations de référence.
La page index.php spécifique à nebule peut appeler par défaut une interface et rester invisible. Mais elle pourra bientôt vérifier aussi que l’interface appelée (un objet nebule) n’a pas été modifiée, dès que sylabe sera intégralement nébulisé.
Cela donne par exemple la page http://stephane.nebule.fr/?bootstrap :

20130819capture

Si on supprime l’option /?bootstrap du lien, on arrive aujourd’hui directement sur sylabe. Cela pourra être personnalisé.

Avancement

Cette fois-ci, la vérification de la signature des liens marche enfin !
C’est une étape importante, la première en fait, puisque c’est ce qui permet de vérifier la validité des échanges, c’est à dire les liens.

Suite à ça, on peut maintenant espérer permettre la génération de nouveaux liens, mais aussi la réception de liens déjà signés. Cette réception marche d’ailleurs, pas la génération, mais si les liens existants sont bien vérifiés, il y a encore un petit bugg qui empêche la vérification d’un lien importé. Ça progresse…
Il y a aussi des variables permettant de désactiver la synchronisation d’objet ou de liens depuis le serveur, mais aussi le transfert d’objet ou de lien vers le serveur. CF upl sur zulu :

capture2013081101

D’un autre côté, il y a des problèmes avec certaines fonctions dans php.
La fonction hex2bin n’est pas reconnu avant la v5.4.0 alors que la fonction inverse bin2hex était déjà présente dans la v4. Il faut à la place utiliser la fonction pack (v4).
La fonction openssl_verify est bien présente depuis la v4.0.4, mais sha256 n’est pas reconnu dans les fonctions de hashage supportées avant la v5.4.8 . Il faut à la place utiliser des fonctions plus basiques comme hash (v5.1.2) et openssl_public_decrypt (v4.0.6). Les anciennes versions stables de Debian et Ubuntu incluaient déjà php en v5.3, je pense que c’est maintenant suffisamment ancien pour ne pas risquer la perte de fonctionnalité.
Donc soit on est compatible uniquement avec des versions très récentes de php, et donc adieux les versions pré-packagées pour serveur (Debian ou Ubuntu par exemple). Bienvenue à la compilation à la demande et tous les problèmes de maintenances inhérents. Soit on utilise d’autres fonctions au prix peut-être de performances moindres, c’est donc le cas pour l’instant, et ça marche :

capture2013081102

Avancement

Je suis toujours en train d’essayer de faire fonctionner la vérification des signatures des liens. Ça ne marche pas mais ça progresse… Je corrige des erreurs au fur et à mesure.

En partant d’un exemple de signature/vérification trouvé sur internet, j’ai pu vérifier que l’ensemble est capable de le faire. C’est ajouté dans le mode log. Cela permet de savoir si le serveur fonctionne correctement et sait signer et vérifier un lien :

capture2013081001

Puisque ce petit bout de code fonctionne, il n’y a pas de raison qu’il ne fonctionne pas ailleurs…

Avancement

Pour cette fois, c’est la possibilité de synchronisation qui a été ajouté. Cela concerne deux choses en fait.

Pour tout objet, on a un lien web dans l’interface qui permet de synchroniser les liens de cet objet sur les entités connues. Ce lien web est présent en haut de la description de l’objet et ouvre un nouvel onglet du navigateur pour afficher l’avancement de la synchronisation. La vérification de la signature des liens n’étant pas encore au point, ces liens ne sont pas inclus localement aux reste des liens.

Pour tout objet dont on ne dispose pas localement d’une copie, on peut essayer de le télécharger chez les entités connues. Ce lien web est présent uniquement avec l’alerte signalant l’absence d’un objet et ouvre aussi un nouvel onglet du navigateur. Si trouvé et valide, le téléchargement de l’objet est effectif.

Voici ce que cela donne, en haut à gauche :

capture01

Et la page de synchronisation ressemble à ça :

capture02

Les liens web dans l’interface, mais surtout cette page, ne sont accessibles que si l’entité est déverrouillée. Cela permet en principe d’éviter le téléchargement d’objets non désirés (malveillant ou autres) sur un serveur.