{{{La gateway}}}
eeVote dispose d'un serveur particulier : la gateway.

C'est par ce serveur que doivent transiter tous les appels distants aux serveurs eeVote.

Ce serveur "gateway" apporte plusieurs avantages :
 - Il permet de n'ouvrir qu'un seul port vers l'extérieur et facilite ainsi la sécurisation du système.
 - Il permet aux applications distantes de n'ouvrir qu'une seule socket, ce qui peut accélérer la communication.
 - Il permettra à terme de vérifier l'identité des applications distantes par échange de clefs, sans avoir à alourdir les appels entre les différents serveurs eeVote locaux


1. Utilisation de la gateway

La gateway est conçue pour être la plus transparente possible vis à vis des applications distantes.

Or la première fonction appelée par toutes les applications avant d'accéder à un serveur est toujours la fonction getServerAccessor du dispatcher.

La gateway doit donc être configurée pour prendre la place du dispatcher et overrider la fonction getServerAccessor.

Soit la gateway est installée sur un ordinateur servant de passerelle, alors que les autres serveurs eeVote sont installés sur d'autres ordinateurs à l'intérieur d'un réseau privé, soit la gateway est installé sur le même serveur que les autres serveurs eeVote.

1.1. Gateway sur un ordinateur servant de passerelle

Dans ce cas, la gateway est configurée pour utiliser le port réservé normalement au dispatcher et c'est elle qui répond à la place du dispatcher.

1.1. Gateway sur le même ordinateur que le dispatcher

Dans ce cas, l'adminstrateur du système doit configurer son fichier firewall, pour couper tous les ports d'eeVote de l'extérieur, sauf le port du dispatcher qu'il redirige vers le port de la gateway.


2. Les ids

Tous les ids d'objets sont complets, même les ids locaux à un serveur.

L'inconvénient : Quand on renomme un serveur Glasnot, par exemple glasnost://toto.entrouvert.org en glasnost://glasnost.entrouvert.org, il faut que la fonction repair de chaque serveur change tous les ids, modifie tous les ids avec une liste des anciens applicationIds à transformer en un nouvel applicationId.
Cet inconvénient est mineur car il suffit de relancer les serveurs. Il n'introduit aucun autre inconvénient.

Ces anciens applicationIds ainsi que le nouveau sont dans le fichier config.


3. Les templates

Les templates doivent être arborescentes. Il doit y avoir une template pour un bouton, une template pour la barre des boutons, une template pour le corps de page, une template pour le header, une pour le footer.
Pour Glasnost, il ne me semble pas que la notion de template soit appropriée, au moins pour l'instant. Quand on met à jour Glasnost, il est préférable de ne ne pas faire planter toutes les versions personnalisées. Il faut donc minimiser le nombre de templates, au moins tant que l'application n'est pas stable.
D'autre part, pour les applications classiques, ce n'est pas le graphiste qui décide de la structure de l'application. Glasnost n'est pas une application marketing. La personnalisation n'a pas à être forcément être extrèmement poussée.
Il faut privilégier au maximum l'utilisation de stylesheets dans Glasnost.


4. La variable req

Dans Glasnost, la variable req de mod_python est utilisée en tant que contexte HTTP.
Il faut progressivement minimiser l'usage de cette variable et la remplacer par la variable context (accessible par getGlobalContext()).


5. Les traductions

Une traduction est ajoutée au serveur de traduction au moment où elle est lue pour la première fois : la plupart des objets sont lus juste après avoir été créés et cela permet de gérer la traduction au niveau du client et non au niveau de chaque serveur. L'inconvénient, c'est que quand un objet est supprimé, les traductions de ses strings restent. Si cela s'avère être un vrai problème, on pourra toujours mettre ultérieurement la création des traductions au niveau de chaque serveur.

Pour avoir le droit d'accéder à une traduction, il faut fournir le texte original (ou au moins son digest, qui en théorie demande forcément le texte original pour être calculé). Il n'y a donc pas de risque qu'un utilisateur puisse accéder à une traduction dont il n'est pas un lecteur autorisé.
Mais le problème se pose pour les traducteurs : il ne faut pas qu'un traducteur ait à traduire un texte qu'il n'a pas le droit de lire. À chaque string est associée un id (de l'object qui contient la string). Avant qu'un traducteur puisse lire une string, le serveur de traduction doit au préalable demander au serveur de l'objet si le traducteur a le droit de lire l'objet en général et la string en particulier.

Certains labels ne sont pas traduisibles, par exemple, celui d'une personne. Dans ce cas, getObjectLabelAndLanguage doit rendre '', pour indiquer que le label n'est pas à traduire.


6. Virtual hosting

Il y a un serveur de virtual host.
Quand on lui fournit l'url il retrouve l'id du virtual host correspondant.
Un virtual host contient l'id, le hostName, le port, le path, la template, sa mainRubric.
Un utilisateur peut être rattaché à plusieurs virtual hosts (qui ne se trouvent pas forcément sur la même machine).
Un article, peut être rattaché à plusieurs virtual hosts. Par défaut, celui proposé est celui actuel, mais un menu propose tous ceux auquel appartient l'éditeur (ainsi que tous ceux qui ont déjà été mis par les éditeurs précédents ?)


5. Notes

La gateway n'est pas un serveur comme les autres, en ce sens qu'elle sert à cacher le dispatcher de l'extérieur et elle en prend la place. Elle ne peut pas être appelée par un serveur eeVote interne et n'est pas enregistrée auprès du dispatcher par un registerServer.


6. À faire
 - Changer la licence de Glasnost (réflexion Afero)
 - Rendre les serveurs réentrants et multi-threaded : c'est indispensable, si les serveurs eeVote sont appelés par plusieurs applications simultanément. Par exemple, 
 - si une application X fait appel à une fonction f du serveur A et que cette fonction appelle à son tour une fonction g du serveur B
 - et si simultanément une application Y fait appel à une fonction h du serveur B et que cette fonction appelle à son tour une fonction i du serveur A,
 - alors on a un deadlock !
 - Donner un wikiName à certains objets (article, person, rubric, ...)
 - Est-ce que le wikiName doit être indépendant du type de l'objet ? Oui.
 - Tous les wikinames doivent être convertis en minuscules. L'espace doit être remplacée par un underscore.
 - Faire les objets systèmes (tous les objets dont le wikiName commence par 'glasnost_').
 - Les objets systèmes ne doivent jamais être référencés par leur id mais par leur wikiName.
 - Transformer la page À propos en article système
 - La moulinette d'extraction des objets systèmes doit vérifier qu'aucun objet système ne contient des ids qui ne sont pas des wikiNames ou qui ne sont pas des wikiNames d'objets systèmes.

7. Bloc notes

 - À faire
  - Supprimer req des getHtml... Quand req est nécessaire, utiliser context.req ?
  - Modifier makeErrorMessage()
  - Déplacer les appels à replaceSpecialTags pour le mettre une fois que l'ensemble du HTML est généré.
  - Modifier Url et UrlNoReq pour qu'elles dérivent de (ou soient remplacées par) la nouvelle classe (ou plutot fonction) X.url ou les classes X.httpUrl, X.glasnostUrl.
  - Supprimer les addId() et remplacer par une X.url (qui donne une une X.glasnostUrl).
  - Supprimer le paramètre req partout et le récupérer par mainModule.context.req.
  - Modifier getContainedMemberIds et getContainedNonMemberIds, pour qu'elles se connectent à un serveur extérieur, quand l'objet examiné n'est pas local (par exemple, un groupe d'un autre serveur Glasnost). Attention aux appels réentrants !
  - Modifier l'exportation et l'importation pour qu'elles utilisent les mêmes fonctions que celles des ObjectWebs et pour qu'elles n'utilisent pas xmlRpcFieldNames, mais un champ xxx_importExport = 1 ou plutot un champ xxx_dontImport = 1 et un champ xxx_dontExport = 1
  - Remplacer getObjectItemLabel par getObjectLabelTranslated en supprimant le userToken.
  - Remplacer getObjectItemLabels par getObjectLabelsTranslated en supprimant le userToken.

 - Fait
  - Remplacé getServerLocation par getServerAccessor.
  - Créé une préférence defaultDispatcheId pour chaque application. C'est le dispatcher auquel se connecte par défaut l'application. C'est un réglage générai, stocké dans mainModule.defaultDispatcherId, et récupéré par getDefaultDispatcherId (de dispatcherProxy), comme getApplicationToken().
  - Remplacé toutes les occurrences de callDispatcher par callServer.
  - Corrigé un bug dans la stylesheet entrouvert2, qui empêchait les pages d'alerte de s'afficher. (Frédéric Péters).
  - Modifié UrlNoReq.addId et webhandler.py pour qu'elles fonctionnent avec des ids distants.
  - Remplacé serverId par serverRole. Par exemple "eePeopleServer" est devenu "people".
  - Remplacé applicationId par applicationName et applicationRole. Idem pour clientId.
  - Supprimé certaines notions de variables globales mises dans mainModule : en effet, bien souvent une variable globale a un module suffit, puisqu'un module n'est en réalité importé qu'une seule fois en mémoire, quoi qu'il arrive.
  - Supprimé les fonctions clone (datant de rig2entrouvert).
  - Modifié _getSetContainedIds, getSetContainedIds, getGroupContainedIds, getObjectContainedIds, getSetDeltaContainedIds, getContainedIds, getContainedMemberIds et getContainedNonMemberIds, et les fonctions appelantes pour qu'elles aients serverRoles en paramètre et non plus serverIds.
  - Dans les articles, remplacé les mots clés des liens par des mots clés anglais.
  - Modifié toutes les fonctions utilisant getWeb(s) ou getProx(y|ies)pour qu'elles fonctionnent avec des ids distants. Attention aux appels réentrants !
  - Ajouté le type "mapping".
  - Remplacé le type "multi" par "sequence".
  - Ajouté une template de fallback. (Frédéric Péters)
  - Ajouté une option pour le tri ou non des sous-rubriques. (Frédéric Péters)
  - Modifié l'index, l'about, les articles, les rubriques, pour qu'ils utilisent des templates. (Frédéric Péters)
  - Création d'un serveur de traduction. (Frédéric Péters)
  - Supprimé l'exception qui se produisait quand la rubrique principale n'était pas lisible par l'utilisateur.
  - Ajouté un fichier translation.py dans common.
  - Remplacé makeObjectsMenu par getObjectLabelsTranslated.
  - Supprimé tous les getObjectsMenu.
  - Rendu le textarea readonly dans ObjectsWeb.
  - Modifié getObjectsSectionLayout, pour utiliser getLabelTranslated au lieu de...
  - Les label dans les handleEditObject ne sont plus traduits.
  - Remplacé None pour les readers et pour les admins.
  - Supprimé les templates inutiles.
  - Supprimé test.py et sample.html.

8. Mise à jour des serveurs XMLRPC

 - Dans les servers :
  - Remplacer isAdmin par self.isAdmin(userToken, xxx)
 - Dans les proxies :
  - Remplacer getApplicationToken() par getApplicationToken(context = context)
 - Rajouter applicationId dans
   - getUserId [authentication]
   - getUserIdAndToken [authentication]
   - checkObjectAuthentication [people]