Archive for the ‘applications’ Category

Dissimulation, transcodage et dossier privé

Samedi, juillet 20th, 2019

La réflexion de l’article Anonymisation/dissimulation des liens – transcodage est très intéressante parce qu’elle rejoint la réflexion originel de nebule implémenté en bash pour les expérimentations. Cette implémentation en bash est clairement mono-entité, c’est à dire à l’usage exclusif d’une entité là où une implémentation en php comme l’application sylabe permet un usage multi-entités simultané.

L’implémentation en bash utilise un dossier nommé /pub pour recevoir les dossiers o et l contenants les objets et les liens dits publiques, ou plutôt publiables. Ce dossier /pub peut être partagé via un serveur web. Mais il y a aussi un dossier nommé /priv qui lui reçoit des dossiers o et l contenants les objets et les liens dits privés, donc non publiables. Le dossier des objets privés permet de recevoir le contenu des objets protégés et déchiffrés le temps de leur utilisation. Le dossier des liens privés n’a jamais été utilisé mais il correspond tout à fait à ce que l’on essaye de faire aujourd’hui avec le transcodage pour les liens de dissimulation.

La structure typique des dossiers de l’implémentation en bash :

/home/user
   +-> /neb
       +-> /pub
       |   +-> /l
       |   +-> /o
       +-> /priv
           +-> /l
           +-> /o

Or le problème de la dissimulation est facile à résoudre sans transcodage dans l’implémentation bash. Mais ce n’est pas transposable dans l’implémentation en php à cause de la notion cité plus haut de capacité multi-entités simultané. Les fichiers transcodés contenants les liens dissimulés répartis par ID d’objets sont le pendant direct des liens du dossier /priv/l.

Liens hypertexte et insertions

Lundi, avril 29th, 2019

Liens hypertexte

Le lien hypertexte a fait le succès de l’Internet en permettant depuis un document HTML de pointer vers d’autres documents HTML, ou d’autres ressources, et sur d’autres serveurs à travers tout l’Internet. C’est tellement pratique que d’autres programmes reprennent le même principe, par exemple les outils de bureautique qui permettent de pointer vers des fichiers externes sur le réseau ou localement sur la machine.

Le lien hypertexte ou ses équivalents utilisent une balise dans le texte du document. Cette balise est interprétée par le programme exploitant le document pour l’utilisateur. Et à la place de la balise on montre à l’utilisateur un contenu descriptif sur la destination comme un texte ou une image.

Dans les objets manipulés par nebule, il est possible d’ajouter une balise propre à nebule. Cette balise ne peut pas être la même que pour un document HTML parce que les objets peuvent ne pas être exploités via une page web. La balise doit se déclarer comme balise nebule et faire référence à un objet avec un élément de remplacement. Dans le cas de l’application sylabe, la balise sera remplacée par un lien HTML pointant vers l’objet mais sur le même serveur web.

Ici pas de nécessité de localisation dans la balise parce que la cible, un objet, est une URI et non une URL. Et le protocole n’est pas précisé parce que c’est le programme qui génère l’affichage qui va se charger de choisir le moyen de renvoie, HTTP, FTP, SMTP, XMPP, etc…

Insertions

Mais de la même façon, une balise peut être utilisée pour non plus renvoyer l’utilisateur vers une ressource externe mais plutôt pour inclure une ressource dans l’affichage présenté à l’utilisateur d’un objet. On obtient ainsi plusieurs contenus affichés en même temps par l’intermédiaire d’un seul objet maître.

C’est ce qui est fait par exemple dans l’inclusion de parties dans une page d’un Wiki.

Cela veut dire que les objets contenus doivent être présents sur le serveur pour permettre un affichage complet. Dans le cas contraire il devra être montré clairement à l’utilisateur qu’une partie du contenu manque.

Chaque objet peut avoir une mise à jour. Il est judicieux pour un même objet maître de ne pas suivre les liens de mise à jour des objets contenus. Mais il est possible de générer et de suivre les mises à jour de l’objet maître intégrant celles des objets contenus.

Traitement social des liens sur liste

Jeudi, février 14th, 2019

Typiquement, dans une conversation, on peut n’afficher les messages que de certaines entités. C’est le cas si on a marqué la conversation comme fermée.

Jusque là on listait les liens de tous les messages de la conversation puis le module filtrait les liens par rapport aux entités de la conversation.

Maintenant, la bibliothèque nebule intègre dans la partie calcul social deux nouvelles façons de filtrer les liens : onlist et offlist
Il faut préalablement envoyer au module de filtre social la liste des ID des entités que l’on veut garder ou filtrer puis appeler le filtre.

Cela centralise le processus et simplifie les applications et modules.

Réorganisation des entités spéciales – gestion

Jeudi, janvier 17th, 2019

Suite des articles Réorganisation des entités spéciales – inventaire de départ. et groupes d’entités.

L’application option permet aujourd’hui d’afficher les autorités globales et locales. Cette interface avec l’instance nebule du serveur doit être le seul point de gestion de ces entités et de leurs rôles. Cette application va donc devoir évoluer pour prendre en compte les évolutions des entités spéciales, et pas seulement les afficher.

Définition des groupes

Dimanche, mai 20th, 2018

La gestion des groupes est entièrement revue et corrigée dans la bibliothèque nebule en PHP orienté objet et dans les applications (sylabe, klicty, messae).
Une fois les applications mises à jour, les groupes existants disparaîtront.

Cet article invalide la définition de groupe telle que définit dans l’article Définition des groupes du 14/01/2016.

Cette implémentation des groupes sera aussi utilisée pour les conversations contenant des messages.

OG / Groupe

Le groupe est un objet définit comme tel, c’est à dire qu’il doit avoir un type mime nebule/objet/groupe.

Fondamentalement, le groupe est un ensemble de plusieurs objets. C’est à dire, c’est le regroupement d’au moins deux objets. Le lien peut donc à ce titre être vu comme la matérialisation d’un groupe. Mais la définition du groupe doit être plus restrictive afin que celui-ci soit utilisable. Pour cela, dans nebule, le groupe n’est reconnu comme tel uniquement si il est marqué de son type mime. Il est cependant possible d’instancier explicitement un objet comme groupe et de l’utiliser comme tel en cas de besoin.

Le groupe va permettre de regrouper, et donc d’associer et de retrouver, des objets. L’objet du groupe va avoir des liens vers d’autres objets afin de les définir comme membres du groupe.

Un groupe peut avoir des liens de membres vers des objets définis aussi comme groupes. Ces objets peuvent être vus comme des sous-groupes. La bibliothèque nebule ne prend en compte qu’un seul niveau de groupe, c’est à dire que les sous-groupes sont gérés simplement comme des objets.

(suite…)

Frontal et relai d’information verrouillé en écriture

Vendredi, avril 20th, 2018

Le mécanisme de transmission d’objets et de liens dans nebule permet de distribuer de façon sûr l’information.

Mais le serveur qui héberge des informations et l’application qui manipule ces informations peuvent tous deux être attaqués afin de corrompre ou supprimer ces informations.

Cette capacité de relais fiable de l’information peut être exploité pour maintenir ‘au chaud’ la source de certaines information et n’exposer publiquement que des relais. On peut même avoir plusieurs couches concentriques de relais, ce qui se rapproche beaucoup du chaînage de proxys web. Mais si le cheminement de l’information s’apparente à des sauts entre relais, chaque relai peut être vu individuellement comme un serveur frontal de partage de l’information. Le rôle de frontal l’empêche de relayer automatiquement une attaque, celle-ci doit d’abord compromettre le serveur frontal avant de pouvoir espérer continuer vers la source de l’information.

Enfin, il est possible de faire transiter de 3 façons différents l’information entre source et relais :

  1. le serveur relai va chercher régulièrement de l’information à synchroniser sur la source (ou un autre relai) ;
  2. le serveur source va synchroniser via une connexion montante, et l’application upload, l’information ;
  3. le serveur source va synchroniser l’information en synchronisant le système de fichier, c’est à dire l’intégralité de l’instance nebule.

Afin de renforcer la robustesse d’une instance de serveur nebule, il est possible d’utiliser l’option de verrouillage globale en écriture. Si cette option est forcée dans le fichier de configuration de l’instance, elle ne peut être modifiée via nebule. Mais si cette option interdit au moteur de la bibliothèque nebule d’écrire quoi que ce soit, cela n’empêche pas le serveur web lui même, une application ou un module compromis, d’écrire. Il est aussi possible de rendre impossible l’écriture des objets et liens en changeant les droits sur le système de fichier contenant la page web. Dans ce cas, seule la synchronisation complète via le système de fichier permet de transmettre l’information.

Ainsi, pour l’entité bachue, maître du code, le serveur qui reçoit le nom de domaine, et donc les connexion, est un frontal qui n’a pas de lien réseau direct vers la source, c’est à dire l’entité bachue elle-même.

Le passage par support amovible (air gap) interdit toute attaque directe de l’entité source.

Copier/coller et marquage

Samedi, mars 3rd, 2018

Dans les différentes applications sont hérités des classes de la bibliothèque nebule un équivalent du copier/coller. C’est un équivalent parce que cela ne fonctionne pas tout à fait pareil.

Copier un objet que l’on collerait ailleurs pourrait se rapprocher de copier un fichier mais cela ne veut rien dire dans nebule parce qu’un objet copié… ne donnerait que l’objet lui même. Seul une transformation (dérivation) donne un nouvel objet à part entière, aussi infime soit la transformation.

De même, un couper/coller n’a pas plus de sens parce que cela reviendrait à retirer un objet pour le remettre au même endroit.

Quand on parle d’endroit d’un objet, techniquement c’est son emplacement de stockage. Mais pour l’utilisateur d’une application cela peut vouloir dire que c’est l’usage de l’objet qui est copié. On copie donc un usage, c’est à dire plus ou moins un lien, d’un objet pour en faire autre chose. Par exemple on peut vouloir faire apparaître l’objet dans plusieurs endroits différents d’une arborescence.
Pour répondre à cette usage sans usurper la fonction de copier/coller, il a été introduit depuis quelques temps dans les applications la notion de marquage. Marquer un ou plusieurs objets permet ensuite d’y faire référence plus tard ailleurs dans l’application, ou dans une autre application. Ainsi, un objet dans une arborescence peut être marqué puis peut être utilisé dans la messagerie pour le transmettre à quelqu’un.

Le marquage peut contenir des objets, y compris sous forme d’entités de groupes ou de messages, et/ou des liens. L’application qui permet l’usage des objets et liens doit faire le tri de ce qui est utilisable pour elle entre les différents types d’objets et les liens.

Il peut être possible de parler d’un vrai copier/coller ou couper/coller d’un objet non pas localement mais entre plusieurs instance de nebule, c’est à dire entre plusieurs serveurs. Le copier/coller reviendrait à une duplication de l’objet sur une autre instance. Le couper/coller reviendrait à dupliquer un objet sur une autre instance puis à supprimer l’objet localement, par exemple pour faire de la place.

Chargement de liens

Samedi, janvier 6th, 2018

Les applications génèrent par elles-même les liens dont elles ont besoin pour répondre aux usages des utilisateurs.

Il est possible de transmettre des liens qui ne peuvent être générés localement. C’est le cas des mises à jours d’applications.
Pour cela, il existe deux méthodes et deux moyens. Le code correspondant à été ré-écrit dans la bibliothèque nebule.

Pour qu’un lien soit traité, il faut que les trois soit validées :

  1. permitWrite : permet d’écrire des objets ou des liens.
  2. permitWriteLink : permet d’écrire des liens.
  3. permitUploadLink : permet de charger des liens.

Les deux méthodes sont :

  • le transfert d’un lien individuel ;
  • le transfert d’un fichier contenant (potentiellement) plusieurs liens.

Les deux moyens sont deux possibilités de transmettre les liens :

  • via l’application upload directement ;
  • via le module module_upload de l’application sylabe.

Lors du chargement d’un lien, quelque soit la méthode ou le moyen, le lien est d’abord vérifié structurellement.
Ensuite la vérification de la signature du lien et de son signataire répond à un processus plus complexe dépendant de deux options et de l’état de connexion d’une entité :

  1. permitPublicUploadLink : permet de charger des liens signés sans qu’une entité en cours ne soit déverrouillée, quelque soit le signataire.
  2. permitPublicUploadCodeMasterLink : permet de charger des liens signés par le maître du code (bachue) sans qu’une entité en cours ne soit déverrouillée.
  3. $this->_unlocked : variable qui donne l’état de déverrouillage de l’entité en cours d’utilisation, càd qu’une entité est connectée.

Si l’entité locale est déverrouillée, le transfert d’un lien devient une action légitime de l’entité. Tous les liens signés sont écrits si ils sont valides (structure et signature). Tous lien non signé est ré-écrit et signé par l’entité en cours; puis écrit.

Cette ré-écriture de lien est une ré-appropriation du lien. Est-ce que cette ré-appropriation peut poser problème ?

Bonne année 2018

Mardi, janvier 2nd, 2018

Une nouvelle année signifie la mise à jour de toutes les dates à côté des licences… que ce soit dans les différents code mais aussi des sites web statiques et des blogs.

Aucune publication de code n’a été faite depuis le 8 mai 2017. Les différentes applications sont toujours en cours de ré-écriture avec la nouvelle partie graphique intégrée à la bibliothèque nebule. Et elles rejoignent progressivement la mise en pratique de la Réflexion sur l’évolution de l’interface web pour nebule. Cependant une publication en cours de migration avec des modifications partielles serait catastrophique pour l’utilisabilité des applications.

Cette focalisation à temps plein sur l’évolution de l’interface est bénéfique à la qualité de l’affichage des applications et à leur utilisabilité. Mais elle est temporaire, pendant ce temps il n’y a de travail ni sur le fond ni sur la théorie et les problématiques spécifiques à nebule.

Références d’images

Samedi, décembre 23rd, 2017

Afin d’accélérer la recherche d’une image à afficher dans une application, en fait en général des icônes, la recherche bascule de la résolution des graphes de mise à jour à l’utilisation de références. Comme définit dans l’article Propriété d’un objet et référence par rapport à un objet, une icône est définit par une référence unique. Cette référence permet de retrouver rapidement un objet. Le gain de temps de traitement est du même ordre que ce qui est décrit dans l’article Objet de référence contre suivi du graphe des mises à jours pour chaque icône, c’est à dire plusieurs fois dans l’affichage d’une page là où le bootstrap n’intervient qu’une seule fois.

Cela peut être utilisé aussi pour rechercher l’image de fond de l’interface même si ce n’est pas une icône.

Chaque icône dispose d’une référence unique, un objet sans contenu, dont l’identifiant n’est visiblement pas une empreinte d’objet.

L’implémentation est fonctionnelle dans la partie graphique de la bibliothèque nebule, reste à convertir toutes les applications et leurs modules…

Modification du thème du bootstrap

Dimanche, octobre 22nd, 2017

Le thème graphique du bootstrap se transforme un peu pour mieux coller à la nouvelle vision développée dans la Réflexion sur l’évolution de l’interface web pour nebule.

L’application 0 voit maintenant ses icônes centrées dans la page et a une icône dédiée au bootstrap/break.

020171022-shot-2017-10-22_18-13-55

Réflexion sur l’évolution de l’interface web pour nebule

Jeudi, juillet 27th, 2017

Au fil du temps l’interface graphique, communément appelée Interface Homme-Machine (IHM), implémentée dans les dérivés de nebule s’améliore et se structure autour de la bibliothèque commune. Cette bibliothèque incorpore de mieux en mieux la préparation de plus en plus d’éléments graphiques communs.

Cependant elle reste insatisfaisante.

Il n’est pas question de parler d’un interface d’application qui apporterait quelques solutions à certains problèmes mais entraînerait de fait bien des problèmes d’interopérabilité et le suivi des codes qui vont avec.

L’interface web semble la plus adaptée aujourd’hui mais traîne malgré sa bonne standardisation la question de la gestion des multiples supports d’affichages. La philosophie habituelle à la mode consiste à faire gérer par même page l’ensemble des affichages possibles dans tout le gradient entre les plus minuscules smartphones et les ordinateurs aux écrans très haute résolution. Sans parler du très faible écart en résolution des écrans à mettre en parallèle à leur l’écart de tailles.

C’est sans compter aussi le questionnement sur l’usage invasif et disproportionné du JavaScript (JS). De plus en plus de pages web sur Internet incorporent des parties de code/JS/images/etc venant de différents CDN. L’éclatement du moteur de la page en de multiples dépendances est tenable avec l’Internet actuel mais est profondément en opposition au fonctionnement de nebule et est par nature très sensible à la fragmentation possible de l’Internet dans le futur. Le JS trop pointu est clairement une source de dysfonctionnement ainsi qu’une source de problèmes de sécurité.

L’interface comporte deux parties:

  1. le contenu de la page contenant l’information principale attendue par l’utilisateur ;
  2. le cadre de la page avec des informations liées à l’environnement de l’information affichée ou à l’application.

Ces deux parties doivent être plus clairement décorrélées graphiquement. L’idée est d’essayer de rendre plus léger, aérien, le contenu et plus discret le cadre.

La vision d’avenir, sauf catastrophe, ce sont d’un côté des écrans toujours plus grands avec des résolutions toujours plus fines. Quand on dit grand c’est vraiment grand, au point que de vouloir mettre en plein écran une application n’ai plus vraiment de sens. Et d’un autre côté une scission des appareils nomades en de multiples composants plus ou moins autonomes parmi lesquels l’écran sera détaché au plus près des yeux de l’utilisateur, là encore avec des résolutions très fortes et avec de la transparence (canal alpha). Il faut aussi voir disparaître le clavier et la souris au profit du tactile, de la commande vocale et du pilotage par les yeux et même via une interface avec le cerveau. Il faut penser dès maintenant à préparer l’affichage des pages pour qu’il y ai une continuité entre la page web affichée aujourd’hui et celle affichée avec les évolutions prévisibles de demain.

La présence quasi systématique du double carré d’un objet peut permettre de le rendre actif en y cachant un menu des actions possibles simplement en cliquant dessus. Ainsi une liste d’objet ne sera plus polluée par de multiples boutons dans le cadre et sous chaque objets. Le menu lié à l’objet est bien sûr contextuel dans l’application et dépendant du type d’objet. Dans la page qui affiche les entités, cliquer sur une entité fera afficher le menu lui correspondant dans lequel on trouvera le bouton qui permet de se connecter avec cette entité.

Dans les menus du cadre ou des objets, l’activation d’un bouton ne sera plus immédiatement suivi d’une action, et d’un rechargement de page, mais fera apparaître des informations plus précises sur l’action du bouton et demandera un déplacement explicite sur un nouveau bouton pour valider l’action. Ainsi ce fonctionnement n’est pas trop pénalisant pour un usage à la souris et est très adapté à l’usage mobile tactile sur de petits écrans.

Les messages qui s’affichent en début de contenu, typiquement des alertes, seront systématiquement affichés à chaque rechargement d’une page mais devront pourvoir être cachés pour mieux accéder au contenu.

L’affichage du contenu doit être centré par défaut horizontalement et verticalement. Sur un écran de petite résolution on doit limiter l’affichage pour avoir juste ascenseur vertical. Sur un écran de haute résolution le cadre sera suffisamment loin pour que tout ce que l’on fait sur l’objet en cours d’affichage soit clairement une action sur l’objet. On peut à l’avenir imaginer que l’espace du contenu dispose de plusieurs zones qui affichent des objets différents simultanément, et donc potentiellement dans des contextes différents.

Le cadre doit contenir les informations sur l’entité connectée et le contenu doit faire référence au besoin à la vue restreinte à une entité si ce n’est pas l’entité connectée.

Réorganisation des entités spéciales – inventaire de départ

Dimanche, juin 25th, 2017

L’organisation actuelle des entités spéciales est assez limitée. On a d’un côté les autorités globales imposées par le code et de l’autre quelques autorités locales aux rôles limités.

Le bestiaire

Premier constat fait depuis un moment, l’entité maître unique puppetmaster est par définition un risque même si pour l’instant c’est la seule façon raisonnable d’avoir une cohérence de l’ensemble. Le but serait d’avoir une entité multi-tête à seuil dont le contrôle est réparti entre plusieurs porteurs. Cette entité n’a que pour mission de désigner les autres entités spéciales globales dont la plus utilisée aujourd’hui est l’entité maître du code bachue. L’entité puppetmaster a un rôle d’autorité et sa portée est globale.

L’entité spéciale cerberus permet de gérer les bannissement d’objets. C’est un peu le rôle de police. L’enfer n’ayant pas encore officiellement ouvert, cette entité n’est pas utilisée mais elle pourrait être très rapidement sollicitée fortement pour tout et n’importe quoi.

L’entité spéciale maître du code bachue est aussi désignée autorité mais est subordonnée au puppetmaster. Son rôle est uniquement de gérer le code sous toutes ses formes.

L’entité spéciale kronos n’a qu’un rôle théorique pour l’instant et n’a que brièvement été utilisée dans des expériences. Cette entité va générer des repères temporels fiables. Mais je pressens qu’elle va devenir incontournable à l’avenir, et peut-être critique pour certains usages.

Enfin, l’entité spéciale asabiyya va être utilisée pour relier les gens avec de la confiance. Elle n’est pas encore utilisée non plus.

Les rôles

On peut distinguer plusieurs catégories d’entités. Les autorités désignes des entités sur des rôles. Les administrateurs font des choix de configuration du code et des applications. Les gestionnaires gèrent des objets, des applications, des entités. Et chaque rôle peut avoir une portée locale ou exceptionnellement globale.

Il existe déjà des méthodes d’organisation qui avaient été retranscrites dans l’article Être relié ou ne pas être. Le modèle RBAC est implémentable par les liens de nebule, le modèle OrBAC semble être moins adapté à nebule parce qu’il sous-entend une une organisation, une structure, qui n’est pas portée par nebule.

La liste de grandes catégories de rôles à compléter peut déjà prévoir l’autorité (authority), la police, l’administrateur (administrator), le gestionnaire (manager), l’entité de recouvrement (recovery)…

L’attribution de rôle est additive, les rôles s’ajoutent à une entité mais il n’y a pas de négation de rôle. Pour les rôles locaux, il est possible de supprimer un rôle d’une entité. Il n’y a pas d’inhibiteur de rôle mais juste un une suppression de lien.

La réflexion continue…

bootstrap – Mise en ligne

Jeudi, juin 1st, 2017

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

Jeudi, mars 30th, 2017

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. (suite…)

Correction dans l’affichage

Jeudi, février 16th, 2017

Une nouvelle version de la bibliothèque a été générée pour corriger un petit problème dans l’affichage des objets.

Cette version sera préparée et mis en ligne plus tard…

Elle est pour l’instant utilisée sur des tests de développement de programmes.

bootstrap – Mise en ligne

Mercredi, décembre 14th, 2016

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

Jeudi, décembre 8th, 2016

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

Jeudi, décembre 1st, 2016

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

Lundi, novembre 28th, 2016

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.