Échange ou téléchargement d’objet et lien de mise à jour

Dans l’article Échange ou téléchargement d’objet, on a vu qu’il y avait deux façons de récupérer le contenu d’un objet. Il y a une deuxième différence qui peut apparaître dans certains cas, c’est la transmission du contenu d’origine ou de celui d’un autre objet si il a été créé un lien de mise à jour de l’objet demandé.

  1. Via un lien web avec comme argument /o/id on télécharge le contenu de l’objet avec comme nom son identifiant id. Les liens de mise à jour ne sont pas utilisés parce que l’empreinte de l’objet est vérifié après téléchargement et que si le serveur envoie un autre objet, fut-il une mise à jour, l’objet sera rejeté.
  2. Via un lien web avec comme argument ?o=id on télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. Mais dans ce cas les liens de mise à jour sont exploités et le contenu renvoyé par le serveur peut ne pas avoir l’empreinte de l’objet demandé.

La prise en compte des liens de mise à jour est toujours délicate parce que cela peut permettre de substituer un objet par un autre. Cette manœuvre est complètement visible dans les liens et nécessite un bon échantillonnage des liens par rapport à leurs poids sociaux.

Échange ou téléchargement d’objet

Un objet peut être récupéré de deux façons.

  1. Via un lien web avec comme argument /o/id on télécharge le contenu de l’objet avec comme nom son identifiant id. L’empreinte est ensuite vérifié pour voir si elle correspond à l’identifiant.
  2. Via un lien web avec comme argument ?o=id on télécharge le contenu de l’objet avec comme nom le nom déclaré par les liens nebule. cela permet de télécharger l’objet sous une forme de fichier classique. On fait ainsi une dé-nébulisation de l’objet. C’est aussi le seul moyen d’avoir accès au contenu protégé hors nebule.

Mais pour un utilisateur, ces deux méthodes ne se valent pas. La première méthode sert à la synchronisation et l’échange d’objets entre programmes et n’a pas pas d’intérêt direct pour l’utilisateur. La seconde lui permet au contraire de reprendre un objet sous une forme classique de fichier.

Actuellement un problème existe dans klicty puisque un objet non protégé peut être téléchargé, c’est le but de l’application, mais c’est fait avec la mauvaise méthode. Donc le fichier téléchargé n’a pas le bon nom. Alors que pour un objet protégé ce problème n’existe pas puisqu’il faut impérativement passer par la deuxième méthode pour avoir accès au contenu non protégé.

La première méthode doit être exclusivement réservée à la synchronisation d’objets.

CF : bootstrap РArguments en ligne et acc̬s directs

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…

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

Mode de récupération

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.