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

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

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

Voici les classes et interfaces actuellement utilisées :

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

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

Avancement de la réimplémentation

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

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

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

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

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

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

Diffusion des mises à jours

L’entité bachue diffuse depuis hier soir les dernières versions de la librairie nebule en php et du bootstrap :

La librairie nebule en bash est en cours de mise à jours vers la version 1.2 .

Parcours restreint de graph de mise à jour

Dans sylabe, la mise en place de la traduction sous forme de modules a apporté son lot de problèmes de sécurité. Les modules peuvent contenir tout un tas de code qui ne sont pas en rapport avec la traduction. Il faut interdire par tous les moyens l’ajout de code malveillant inconnu. Il est très difficile de filtrer finement ces codes pour ne garder au mieux que ce qui concerne les traduction ou au pire rejeter l’objet qui le contient. La solution retenu est de ne reconnaître que les modules signés soit par bachue, soit par l’entité locale.

Les fonctions _l_grx et _l_gr1 de la librairie en php prennent maintenant en compte un paramètre pour restreindre la recherche des liens de mise à jours (résolution du graphe des mises à jours) aux deux entités citées ci-dessus.

Mais, si fonctionnellement c’est suffisant, on va maintenant plus loin. Au lieu de ne reconnaître que deux entités, il est maintenant possible d’en ajouter plus de façon statique. On crée en quelque sorte une liste d’autorités locales. Cette liste n’est valable que sur un serveur et pour une seule instance de sylabe ou tout autre programme similaire.

Ainsi, la variable $nebule_local_authority contient une liste des entités faisant office d’autorité locale. Elle est pré-remplie par défaut avec l’entité bachue. Elle peut être complétée.

Une autre variable $nebule_curentnotauthority permet d’interdire à l’entité courante d’être elle aussi autorité locale. A false par défaut, l’entité locale peut ajouter des modules. C’est notamment pratique pour le développement puisque l’on peut faire soi-même des évolutions de ces modules. A true, l’entité locale ne peut qu’utiliser les modules par défaut présents localement.

Il est bien sûr possible de positionner ces deux variables dans les fichiers de configuration env_nebule.php et env_sylabe.php. Cependant, leur comportement est un tout petit peu différent dans le bootstrap et dans la librairie (via une application comme sylabe).

Quelques explications s’imposent pour comprendre les différences. Schéma de fonctionnement global d’une instance :

1 – Appel du bootstrap (index.php) par le serveur web.
V
2 РEx̩cution du script php.
3 – Lecture du fichier de configuration env_nebule.php.
4 – Recherche de la librairie nebule valide à charger.
5 – Chargement de la librairie nebule (fonctions et variables).
6 – Recherche de l’application par défaut et valide.
(actuellement, c’est sylabe)
7 – Le bootstrap charge l’application et passe la main.
V
8 – Exécution du script php de l’application.
9 – Lecture du fichier de configuration env_sylabe.php.
10 – Déroulement du script de l’application…

Lors de l’exécution du bootstrap, celui-ci n’utilise pas la session utilisateur gérée par php. Il va cherche si le fichier e existe et si c’est une entité. Il prend cette entité comme étant l’entité propriétaire de l’instance. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses mises à jours seront prises en compte. Ainsi, il n’est pas possible pour l’entité locale de modifier la librairie ou le programme (sylabe) sauf si ils sont signés par bachue. Une mise à jour régulière est possible.

Lors de l’exécution de l’application, ici sylabe, l’entité locale n’est pas forcément l’entité courante. Et l’entité courante n’est donc pas forcément propriétaire de l’instance mais juste utilisatrice. Si avec la variable $nebule_curentnotauthority on empêche de reconnaître cette entité comme autorité, seule bachue sera autorité et donc seuls ses modules seront pris en compte. Ainsi, il n’est pas possible pour l’entité courante de modifier les modules. Une mise à jour régulière est possible.

En clair, l’entité locale choisit la librairie nebule et le programme à charger, l’entité courante dans le programme choisit les modules. Si cela ne leur est pas interdit.

Pour ajouter d’autres autorités, il suffit de les ajouter à la variable $nebule_local_authority dans les fichiers de configuration :
$nebule_local_authority[]='88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea';

shot-2014-05-19_12-24-40

Métrologie et journalisation

La métrologie est ajoutée dans la librairie en php de nebule et est complétée dans sylabe.

La journalisation (log) est ajoutée au bootstrap et à la librairie php. On peut consulter les logs du système, cela ressemble à ça :

May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(start)1400248715.3933
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark1)1400248715.3957
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark2)1400248715.3961
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark3)1400248715.7138
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark4)1400248715.7139
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark5)1400248715.7303
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(mark6)1400248715.7304
May 16 15:58:35 gaia nebule/bootstrap/99df1611: metrologie(end--)1400248715.7304
May 16 15:58:35 gaia sylabe/99df1611: metrologie(start)1400248715.7669
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark1)1400248715.8505
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark2)1400248715.8683
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark3)1400248715.8755
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark4)1400248715.8756
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark5)1400248715.8992
May 16 15:58:35 gaia sylabe/99df1611: metrologie(mark6)1400248715.9034
May 16 15:58:36 gaia sylabe/99df1611: metrologie(mark7)1400248716.0637
May 16 15:58:39 gaia sylabe/99df1611: metrologie(mark8)1400248719.8376
May 16 15:58:39 gaia sylabe/99df1611: metrologie(end--)1400248719.8378

Dans la librairie, les marques de passage dans les fonctions et les temps sont envoyés dans les logs système (syslog) moyennant le contrôle par les variables $nebule_timedebugghf et $nebule_timedebuggef. La distinction se fait sur les fonctions de haut niveau et les fonctions élémentaires. Aucun log n’est prévu sur les fonctions de bas niveau. Si on active les deux, ça débite pas mal…

Bootstrap php et chargement de code à la demande

Le bootstrap reconnait deux options en ligne bootstrap_load et bootstrap_lib. CF sybale – avancement du 02/03/2013.

Ces options ont pour but de permettre de choisir spécifiquement une version de sylabe et une version spécifique de la librairie php. Ce sera utile lors de problèmes de cohérences entre les versions de sylabe et de la librairie. Une incohérence peut conduire dans le cas d’une fonction absente à une erreur php, et donc à un affichage vide. Dans ce cas, forcer les versions permet de revenir à une situation stable et de corriger tranquillement le problème.

Mais ce mécanisme entraine un problème de sécurité. Il est possible de forcer ces options à la main et donc de choisir volontairement des versions de code anciennes, défectueuses ou mal protégées. Ce problème ne peut être résolu directement dans sylabe puisque les choix de codes se font dans le bootstrap. Il faut donc trouver et implémenter un mécanisme pour soit restreindre soit désactiver ces deux options directement dans le bootstrap. Il sera toujours temps de les réactiver le temps de résoudre un problème.

  • Une des solution serait de vérifier site web de provenance et de rejeter les options si ce n’est pas en accord avec l’URL courante. Mais cette valeur peut elle aussi être forgée.
  • Une autre solution peut être de tenir compte des listes de bannisement pour éviter certains codes anciens. Mais cette liste ne va pas protéger des codes malveillants insérés sur le serveur.
  • Enfin, on peut prévoir un fichier d’environnement pour le bootstrap, ou plus simplement la prise en compte des options si un certain fichier est présent.

La suite au prochain épisode…

Migration du bootstrap et de la librairie

Jusque là, le code du bootstrap et de la librairie nebule en php était dépendant du projet sylabe.

Maintenant, ils sont détachés du projet sylabe et sont directement rattachés au projet nebule, ce qui est plus cohérent. Le projet sylabe va cependant continuer à s’appuier sur le bootstrap et la librairie nebule et même à les faire progresser.

Les codes actuellement en ligne, diffusés par l’entité bachue, sont disponibles ici :
bootstrap
librairie

CF : Projet sylabe – Migration du bootstrap et de la librairie