More additional considerations -- Autres considérations

Date de publication: le samedi 26 novembre 2011 à 00h34
Dernière modification: par Pascal BOYER le lundi 28 novembre 2011 à 01h02

27 May 2010 5:36:44

Shared Content Classes

In this example we've used the same database and var directory for both public sites. Though the content is in separate subtrees, the content classes they use are shared. Be careful not to change attributes in a class to suit one site if they're needed by the other site. If this might become a problem, you could use a separate database and var directory—or more simply, each site could use different content class groups.
Nous avons utilisé dans cet exemple la même base de données et le même répertoire var pour les deux sites publics. Bien que le contenu se situe dans des sous-arborescences distinctes, les classes de contenu sont partagées. Soyez donc attentifs, pour convenir aux besoins d'un site, à ne pas modifier des attributs de classes utilisées par l'autre site. Si cela s'avère un problème, vous pouvez utiliser des bases de données et des répertoires var différents - ou plus simplement, chaque site peut utiliser des groupes de classes différents.

Content Sharing / Partage de contenu

Copying an object or subtree is of course a simple way of getting content into a second subtree (website) when the database is shared by two sites, but then changes to one copy will not appear on the other. In the same scenario, you can easily share content by using secondary/additional locations. That's an easy way of sharing content, but it must be done for each individual object (the children of the shared object do not automatically get shared as well). A workflow (“after publishing”) could be used to publish all articles in one subtree in another subtree (on the second site) as well. Another way to pull content from one database to another would be using an RSS feed.
Copier un objet ou une partie de l'arborescence constitue bien sûr un moyen simple de disposer d'une seconde sous-arborescence (d'un second site web ) lorsque la base de données est partagée par deux sites, mais alors, les modifications apportées à l'une n'affecteront pas l'autre. De même, vous pouvez facilement partager du contenu en lui associant des emplacements supplémentaires. Bien qu'il s'agisse-là d'une méthode facile pour partager du contenu, elle doit être répétée pour chaque objet à partager (les enfants d'un objet partagé n'étant pas automatiquement partagés). Un workflow after publishing peut être mis en œuvre pour publier tous les articles d'une sous-arborescence vers une autre sous-arborescence (du second site). Une autre moyen de pousser du contenu d'une base de données vers une autre serait d'utiliser un flux RSS (???).

Security / Sécurité

It is more secure to use separate databases and var directories for separate sites. It may be best to always use separate databases and var directories unless the siteaccesses need access to some of the same content or users in an easy way. If you do have a database and var directory for each public siteaccess, each public siteaccess will need a corresponding admin siteaccess.
Il est plus sûr d'utiliser des bases de données et des répertoires var/ séparés et il est toujours préférable de procéder à cette séparation à moins que les siteaccess n'aient besoin d'accéder facilement à certains contenus ou utilisateurs. Dans l'hypothèse où vous utiliseriez des bases de données et des répertoires var distincts, chaque siteaccess devra être alors également associé à un siteaccess d’administration propre.

User and access control management / Gestion des utilisateurs et du contrôle d'accès

A Single Sign On (SSO) capability is sometimes required, letting a visitor log in with one single set of access credentials on a series of websites. This can be easily achieved when the content is shared between siteaccesses (one subtree per site), for the users (stored as other content objects) are natively shared. When the content base is not shared, dedicated SSO solutions, such as LDAP or Active Directory, must be used. eZ Publish natively supports LDAP as an SSO system, and its architecture can make use of any SSO-plugin. The latter take the form of an extension, and can interface eZ Publish with basically any SSO system. More on SSO extensions here : http://share.ez.no/articles/ez-publish/using-a-sso-in-ez-publish.
Une authentification unique (Single Sign-On - SSO) est parfois requise, permettant à un visiteur de se connecter à une série de sites web avec un unique jeu d'identifiants. Ceci est très facile à mettre en place lorsque le contenu est partagé entre plusieurs siteaccess (une sous-arborescence par site), quant aux utilisateurs (enregistrés en tant qu'objets) ils sont nativement partagés. Lorsque la base de contenus n'est pas partagée, des solutions SSO dédiées, telles que LDAP ou Active Directory, doivent être envisagées. Bien qu'eZ Publish supporte nativement LDAP en tant que système SSO, son architecture peut utiliser n'importe quel plu-in SSO. Ce dernier prend la forme d'une extension et peut interfacer eZ Publish avec pratiquement tout système SSO. Vous trouverez de plus amples informations sur SSO ici: Using-a-sso-in-ez-publish .

Concerning access control, user roles can be applied with subtree limitations, and we now know each website can be a subtree. In our example, care would need to be given to ensure the node 2 is not tampered with, and that the name of the landing page nodes is not changed without an appropriate configuration file change. This can be assured by changing user roles and policies in the administration interface. Having roles applied with subtree limitations eases access control administration. This generic benefit makes a whole lot of sense in our example : the few user profiles are identified, across the two public sites we built, then materialized as roles. Typically, a logged-in user on both site 1 and site 2 can read content from the standard section, the media library, and create & edit blog posts. However, they should not be able to read or edit content from the other website (ie: form the other subtree). To satisfy this :
Concernant le contrôle d'accès, les rôles des utilisateurs peuvent s'appliquer sur la base de limitations au niveau des sous-arborescences et nous savons maintenant que chaque site peut être une sous-arborescence. Dans notre exemple, il faudrait prendre soin de s'assurer que le nœud 2 ne soit pas altéré et que les noms des nœuds des pages d'accueil n'aient pas été modifiés sans que soient également correctement modifiés les bons fichiers de configuration. Pour garantir cela, il faut modifier les rôles et les permissions des utilisateurs à partir de l'interface d'administration. Disposer de rôles dont les limitations portent sur les sous-arborescences facilite l'administration du contrôle d'accès. Cet avantage prend tout son sens dans notre exemple: les quelques profils utilisateurs sont identifiés, sur les deux sites publics que nous avons construit, puis matérialisés en tant que rôles. Typiquement, un utilisateur connecté aux deux sites 1 et 2 peut lire le contenu de la section standard, la médiathèque et créer/éditer des billets du blog. Il ne pourra cependant pas lire ou éditer du contenu appartenant à l'autre site (i.e: placé dans l'autre sous-arborescence). Pour satisfaire ceci:

• One single role is crafted, containing the handful of policies described above
  Un unique rôle est créé, contenant un ensemble de permissions décrites ci-dessus.

• Two user groups are created : “Editors site one” and “Editors site two”, self explanatory.
  Deux groupes d'utilisateurs sont créées: Éditeurs site un et Éditeurs site deux

• The role is applied to both user groups, with subtree limitation on their respective website's subtree.
  Le rôle, appliqué aux deux groupes d'utilisateurs, dispose de limitations s'appliquant respectivement à la sous-arborescence de chaque site.

Commentaires