Archive for the ‘Implémentation’ Category

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

Mardi, juin 6th, 2017

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.

Modification des sources d’aléa

Samedi, juin 3rd, 2017

La bibliothèque nebule en PHP orienté objet présente deux fonctions de génération d’aléa dans la classe dédiée à la cryptographie.

Les fonctions :

  • public function getPseudoRandom($size=32)
  • public function getStrongRandom($size=32)

La première fonction getPseudoRandom permet de générer un aléa correct mais pas fiable, c’est à dire de qualité mais pas pour un usage cryptographique sûr. Il va servir principalement pour générer des identifiants d’objets de références.

La seconde fonction getStrongRandom permet de générer un aléa beaucoup plus fiable, c’est à dire réellement non prédictible, pour un usage cryptographique sûr. Cependant cet aléa est précieux parce que sa génération prendre du temps et peut consommer des ressources, ce qui limite la quantité de bon aléa que l’on peut demander à un instant donné. Il doit donc être réservé strictement à des usages requérant un aléa fiable.

Or, la fonction getPseudoRandom fait appel à la même fonction interne openssl_random_pseudo_bytes que getStrongRandom, ce qui veut dire qu’elle consomme de l’aléa précieux alors que ce n’est pas nécessaire.

Cette fonction getPseudoRandom va être modifiée pour générer un aléa correct mais non fiable à partir de la date/heure et une préparation via une ou plusieurs fonctions de hachage. Elle ne devra en aucun cas être utilisée comme source pour générer des mots de passes de session ou de protection des objets, etc… nécessitant un aléa de qualité cryptographique.

Bugg d’affichage des autorités globales dans option

Vendredi, juin 2nd, 2017

Il y a un petit problème dans l’affichage des autorités globales dans l’application option. Par exemple ici :

https://sylabe.com/?a=21215100000000…0000000212151&view=gauth
shot-2017-06-02_19-51-13

Mais une partie de l’affichage est bon est correspond bien à l’entité bachue qui gère le code. Un petit tour par le bootstrap permet de s’en assurer :

https://sylabe.com/?b
shot-2017-06-02_19-57-13

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…)

Échange ou téléchargement d’objet

Mardi, mars 28th, 2017

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

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 – configuration

Samedi, décembre 10th, 2016

Suite des articles Entités de recouvrement et implémentation.

L’objet de référence de définition des entités de recouvrement est l’objet contenant :

nebule/objet/entite/recouvrement

De nouvelles options permettent de gérer la prise en compte des entités de recouvrement par la bibliothèque nebule en PHP :

  1. permitRecoveryEntities (boolean, critical) : commutateur global d’activation des entités de recouvrement via les liens des autorités strictement locales. Par défaut à false.
  2. permitRecoveryRemoveEntity (boolean, careful) : commutateur qui permet à une entité de supprimer le partage de la protection d’un objet avec une entité de recouvrement. Par défaut à false.
  3. permitInstanceEntityAsRecovery (boolean, critical) : commutateur de définition de l’entité instance locale comme entité de recouvrement. Outrepasse les liens. Par défaut à false.
  4. permitDefaultEntityAsRecovery (boolean, critical) :commutateur de définition de l’entité par défaut comme entité de recouvrement. Outrepasse les liens. Par défaut à false.

Toutes les options sont en lecture seule, c’est à dire que les liens d’options ne sont pas pris en compte. Au besoin, ces options doivent être modifiées dans le fichier d’environnement.

A false, par défaut, la première option désactive complètement la détection des entités de recouvrement et le mécanisme de partage de protection des objets pour les entités de recouvrement.

La deuxième option, si à true, permet à une entité de supprimer le partage de protection à une entité de recouvrement particulière. Cette action doit être faite après la protection, réalisée systématiquement, et sur tous les objets protégés un par un. Cette option va faire disparaître le bouton de suppression de partage de protection dans les affichages, mais elle est aussi vérifiée lors de la suppression effective du partage de protection d’un objet si l’utilisateur tente la suppression de force.

Le lien de déclaration d’une entité de recouvrement a la forme :

  • action : f
  • source : entité instance locale, par exemple = 3af39596818c1229d7a3d08b9f768622903951305df728609a68a2957f7f3882
  • cible : entité de recouvrement, par exemple = 19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
  • méta : objet de référence de recouvrement

La désactivation est un lien de type x.

Les liens doivent être signés de l’entité instance locale ou de l’entité par défaut en fonction des options de permission.

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.

bootstrap – Désactivation des applications par défaut

Dimanche, novembre 27th, 2016

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

Dimanche, novembre 27th, 2016

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

Jeudi, novembre 24th, 2016

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

Lundi, novembre 21st, 2016

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 – affichage

Samedi, novembre 19th, 2016

Suite de l’article sur le Renforcement de la lecture des objets, et type hash invalide.

L’argument $permitTruncate ayant disparu, c’est aussi l’option displayUnverifiedObjects qui n’a plus de raison d’être. Les fonctions d’affichage qui auraient pu devoir afficher un objet trop gros pour le vérifier n’en verront plus dans tous les cas.

En échange, une nouvelle option permitCheckObjectHash est mise en place dans la bibliothèque nebule en PHP orienté objet.
Elle est utilisée dans la fonction _getUnprotectedContent(). Elle va activer la vérification de l’empreinte des objets lus, ou plutôt forcer la lecture de l’objet même si son empreinte est invalide ou non vérifiable. C’est le pendant de l’option permitCheckSignOnVerify ayant la même signification pour la vérification des liens. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

Renforcement de la lecture des objets – type hash invalide

Vendredi, novembre 18th, 2016

Dans l’article sur le Renforcement de la lecture des objets, il était question notamment de la possibilité de supprimer ou pas un objet dont on ne peut pas vérifier l’empreinte parce que le type de hash est soit inconnu soit non reconnu.

Lors de l’échec de la récupération du type de hash de l’objet, on essaye tout de suite, si l’option permitSynchronizeLinks est à true, de synchroniser rapidement les liens de l’objet. Puis on essaie de relire le type de hash de l’objet.

Une nouvelle option permitDeleteObjectOnUnknowHash vient d’être ajoutée. Elle a true comme valeur par défaut. Elle n’est pas modifiable par lien, pour changer sa valeur par défaut il faut modifier le fichier des options.
Cette option est critique, elle doit toujours rester par défaut à true !

La nouvelle option est utilisée par la bibliothèque nebule en PHP en programmation orienté objet (library POO) par les fonctions checkConsistency() et _getUnprotectedContent() de la classe Object. La fonction _getProtectedContent() ne prend pas en compte cette option, elle se base uniquement sur _getUnprotectedContent() pour la lecture de l’objet protégé et de la clé de déchiffrement associée.

L’implémentation de l’option est un tout petit peu différent ce que l’on peut attendre. Lorsque l’on recherche le lien du type d’empreinte d’un objet (avec la pondération sociale), si aucun lien n’est trouvé ou si le nom de l’algorithme de prise d’empreinte n’est pas reconnu, alors il y a deux possibilités.
L’option permitDeleteObjectOnUnknowHash est à :

  1. false. Dans ce cas les deux fonctions retournent tout de suite un résultat booléen négatif ou un contenu vide.
  2. true. Comme aucun algorithme n’est trouvé, on utilise l’algorithme définit par défaut et on continue le processus de vérification dans les deux fonctions. Si l’empreinte ne correspond pas avec cet algorithme, l’objet est supprimé. C’est une façon de donner une chance à un objet pour lequel les liens auraient été partiellement synchronisés.

Dans la bibliothèque nebule en PHP en programmation procédurale (library PP), la lecture des objets se fait via les fonctions _o_ls1 et _o_lsx. La deuxième repose en fait sur la première. Et en début de fonction _o_ls1, un appel à la fonction _o_vr permet de vérifier le contenu de l’objet.
La fonction _o_vr ne prend en compte que les objets avec un hash fait avec l’algorithme par défaut, aujourd’hui sha256. L’option permitDeleteObjectOnUnknowHash n’est pas utilisée.

Dans les deux bibliothèques, si c’est l’objet avec d’identifiant 0, alors il est systématiquement supprimé.

Enfin, dans tous les cas, il ne faut surtout pas tenter de vérifier l’empreinte avec tous les algorithmes disponibles, cela reviendrait à permettre une attaque sur le plus faible de ceux-ci…

Renforcement de la lecture des objets

Jeudi, novembre 17th, 2016

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

Samedi, novembre 12th, 2016

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…