Mois : février 2011

Nous utilisions une solution ‘maison’ pour le partage des sessions entre les serveurs.

Aujourd’hui, en travaillant sur l’installation de l’éditeur, un ‘bug’ est survenu. Une erreur survenant après le code, je n’avais jamais vu ça. En fait il s’agissait d’une manipulation simultanée d’une session à 2 endroits. Évidemment ça ne va pas, il n’y a pas de ‘lock’ dans le système actuel.

Je remercie d’ailleurs Patrick A. pour ses connaissances de la mécanique interne de PHP qui m’a permis de corriger partiellement le système de session ‘maison’.

Mais cela n’est pas suffisant, le problème reste entier, juste la conséquence était maitrisée. Il faudrait implémenter un système de lock avec le document de session. De plus on m’a fait remarqué la lourdeur/lenteur des opérations avec ce système ‘maison’.

Enfin soit, l’expérience fonctionne mais ne convient pas à Be a Buzz.

C’est là que je repense à NFS pour y mettre en mode natif les sessions.

2 lignes de codes et 2 fichier de conf après c’était modifié et fonctionnel. J’espère pour un mieux et l’erreur de lock en moins.

Je suis certains que ce foutu système de session m’en fera encore voir à l’avenir car il peut encore être amélioré en terme de vitesse et de place occupée en un point central critique.

La base de l’éditeur, qui était le point de test et d’échec, va enfin pouvoir continuer sereinement. Je pense avoir correctement défini le principe.

Programme de la suite

– continuer l’éditeur
– Implémenter la connexion globale (Single Sign On)
– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer 3 nouveaux Buzz

—
t+=8h=94h30;

Comme je l’expliquais hier, nous avons un soucis de communication. J’explore une hypothèse ou un module central répondrait à la demande, il serait disponible pour chaque Buzz évitant ainsi le trou de sécurité des autres solutions listées.

L’éditeur va pour ainsi s’installer dans le Buzz connecté selon les accès reçus, proposer l’interface et en charger d’autre tout en passant par le flux principal.

Là où ça se corrompt c’est qu’il ne s’agit pas d’une page mais d’un module dynamique, il n’est donc pas ‘pagé’, le système ne traite que des pages, du moins via requêtes traditionnelles. Cette requête sera standard mais annoncera ça différence pour qu’à certains endroits bloquant du processus elle puisse passer outre certaines vérifications. Ceci évidemment sans remettre en cause la sécurité.

On pourrait dire qu’il ne s’agit pas vraiment de corruption mais de négociation afin d’arriver à un résultat : un éditeur centralisé et disponible malgré les différents domaines pouvant communiquer en retour au central pour enregistrer les modifications.

Programme de la suite

– continuer l’éditeur
– Implémenter la connexion globale (Single Sign On) – y a de l’idée, mais c’est compliqué
– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Installer le site mère
– Installer 3 nouveaux Buzz

—
t+=2h=86h30;

C’est ainsi, rien n’est simple. On a un flux, complexe vu de l’extérieure je vous l’accorde, mais quand on s’en approche et qu’on apprend à le connaître… non en fait il reste complexe mais au moins on a appris à le connaître.

Il faut dire que le sujet ‘cross domain’ est un vrai calvaire. Tant point de vue sécurité que les aspects à considérer. Néanmoins, après moult recherches, essais et diverses tentatives une solution acceptable apparait, une fois testée, peut-être, qu’elle sera plus qu’acceptable.

Côté designs, ça avance, les minibab (login, err) sont quasiment fonctionnel.

Point de vue gestion du flux et informations, certaines améliorations ont été mise en place pour augmenter la flexibilité et l’usage.

Programme de la suite

– continuer l’éditeur
– Implémenter la connexion globale (Single Sign On) – y a de l’idée
– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)

—
t+=6h=84h30;

Suite logique de hier, je me suis attaqué au menu de la page de connexion qui me sert de test en ce moment.

Le principe fonctionne et doit être encore étoffé pour des designs plus complexes.

Toujours dans l’idée de finir ce qui est commencé, le système d’authentification fonctionne et a permis de déceler une erreur glissée dans le système de session.

Le système de contenu structuré continue de faire ses preuves, une vrai belle trouvaille.

Le système de centralisation des erreurs et de guide a été amélioré. Le sous-système interne de gestion d’erreurs propre au système de la V5 a été remplacé par une centralisation dans le module spécifique.

Programme de la suite

– Fixer le design des menus
– Définir les contenus secondaires (bordures, arianes, …)
– Implémenter la connexion globale (Single Sign On)
– Débuter l’éditeur

—
t+=4h30=78h30;

Une bonne journée, le flux de génération de page a été complété. Certes il reste des détails, du développement et des affinages à faire mais le principe des étapes est complet.

Tout a été adapté pour cette version et les tests sont parfaits.

Programme de la suite

– Finir err et login côté dynamisme
– Implémenter la notion de menu et penser la manière de les styler.

—
t+=3h=74h; (?)

Hier, jour non répertorié, s’est déroulé une réunion de finalisation des designs généraux d’erreur, de login et d’installation.

On a remis en cause et défini la structure des designs, une bonne chose de faite !

L’installateur a été revu et fort simplifié, plus de confort pour l’utilisateur et moins de question à se poser avant d’avoir son buzz.

Err et Login ont pu être mis en place, corrigé et testé aujourd’hui même. Le dynamisme de ces pages, ayant leur module propre, a également été testé avec succès.

Grande réflexion sur la bonne manière de faire au niveau des contenus, gestion du dynamisme et éditions. Il y a des idées, reste à fixer tout ça.

Programme de la suite

– Finir err et login côté dynamisme
– Corriger certaines erreurs remarquées
– Fixer la manière de stocker le contenu
– Implémenter la notion de menu et penser la manière de les styler.
– La suite on verra 😉

—
t+=7h=71h;