- Wikitty-devel - mailman.cloud.codelutin.com

Specs de sécurité et de localisation wikitty
by Jean Couteau Aug. 9, 2010

Aug. 9, 2010

Suite à une réflexion sur la sécurité et la localisation de wikitty, voici ce qui avait été prévu (ça fait un peu de temps que c'est sur le svn, mais mieux vaut tard que jamais). (Extrait de : http://svn.nuiton.org/svn/wikitty/trunk/src/site/rst/Spec.rst) Gestion des droits ================== Utilisateurs et groupes ----------------------- Les utilisateurs ont un nom et un mot de passe, les groupes contiennent des utilisateurs (d'autres groupes ?) Par dÃ©faut il existe un *WikittyGroup* portant le nom **WikittyAppAdmin**. Si ce groupe n'existe pas ou qu'il est vide, cela indique que tous les utilisateurs sont AppAdmin. Cela est nÃ©cessaire pour deux choses: - pour permettre d'avoir une authentification, mais que l'on ne souhaite pas de gestion d'autorisation. - pour servire de bootstrap au lancement de l'application seul les AppAdmin peuvent modifier le *WikittyGroup* portant le nom **WikittyAppAdmin**, or s'il est vide il faut pouvoir le remplir. Il ne doit donc exister un seul *WikittyGroup* portant le nom **WikittyAppAdmin** Tokens de sÃ©curitÃ© ------------------ Ã€ chaque login, un token de sÃ©curitÃ© est fourni Ã l'utilisateur. L'utilisateur doit fournir ce token Ã chaque opÃ©ration pour montrer qu'il a les droits. Pour un token donnÃ©, on peut savoir Ã quel utilisateur il appartient. Les tokens sont stockÃ©s en base et supprimÃ©s au logout de l'utilateur. Les SecurityToken ne sont supprimÃ©s de la base de donnÃ©es qu'au moment du logout Si les utilisateurs/applications quittent sans faire le logout le nombre de SecurityToken ne fera qu'augmenter. Pour Ã©viter cela, il faut prÃ©voir un petit job qui de temps en temps fait le mÃ©nage dans les SecurityToken trop vieux. Gestion des droits sur un Wikitty --------------------------------- Un wikitty a plusieurs extensions, pour chacune de ces extensions, on a plusieurs droits. On distinque quatre niveaux de droits : * owner (un utilisateur) donne tous les droits sur un wikitty * admin (zÃ©ro ou plusieurs utilisateurs / groupes) permet d'ajouter ou de supprimer des Ã©lÃ©ments dans writer et reader * writer (zÃ©ro ou plusieurs utilisateurs / groupes) permet, pour chacun des champs de cette extension, de modifier la valeur * reader (zÃ©ro ou plusieurs utilisateurs / groupes) permet, pour chacun des champs de cette extension, de lire la valeur Si on veut que tout le monde puisse lire un wikitty, il faut laisser vide la liste des readers (vide ou null). Si l'on souhaite indiquer que personne ne peut lire l'objet il faut mettre le owner en tant que reader. Car de toute faÃ§on l'owner aura toujours le droit en lecture. La granularitÃ© est donc au niveau des extensions. C'est Ã dire qu'avoir le droit reader de l'extension Ext permet de lire tous les champs de l'extension Ext de tous les wikitty qui ont l'extension Ext. Gestion des droits sur les extensions ------------------------------------- Pour chaque extension, on a la mÃªme hiÃ©rachie de droit qui donnent des possibilitÃ©s diffÃ©rentes : * owner : * admin : permet de changer les droits de l'extension. Donc, permet d'ajouter ou de supprimer des Ã©lÃ©ments dans writer et reader * writer : permet de modifier l'extension l'extension * reader : permet de lire l'extension pour en crÃ©er des instances. Si le reader est vide, tout le monde peut crÃ©er. Pour que seuls les AppAdmin et le owner puissent crÃ©er des instances, il faut mettre le owner en reader. Si une extension ne dispose pas de ces informations, seuls les AppAdmin peuvent crÃ©er les instances et modifier l'extension. Comment ces droits sont stockÃ©s ------------------------------- Pour chaque extension connue, il y aura donc un wikitty dont le seule extension sera WikittySecurity. Chacun de ces wikitty aura pour identifiant Â« WikittySecurity'ExtensionName' Â». Pour stoker les droits qui portent sur les extensions, on fait appel Ã des **meta-extensions**. Une Pseudo extension est portÃ©e par les extensions du wikitty. Exemple avec WikittySecurity sur un Wikitty Personne qui a une extension Employee et Customer. Il y a une extension Employee:WikittySecurity et une extension Customer:WikittySecurity. le sÃ©parateur de pseudo-extension = ':' comme css Localisation ============ On rajoute une pseudo extension WikittyI18n aux extensions du wikitty. Cette pseudo-extension a deux champs : langue et translation personne:wikittyI18n.langue=fr,en,es personne:wikittyI18n.translation=[fr:name=prÃ©nom,surname=nom],[en:name=name,surname=surname] personne.name=value ton extension : security dezs champs de sÃ©curitÃ© ton extension : i18n des champs i18n ton extension.champs=valeur dans la langue un wikitty ne peut exister que dans une langue Ã la fois, si tu veux plusieurs langues, tu charges plusieurs fois le wikitty. du coup ton wikitty a une version et une langue. On stocke dans la dÃ©finition de l'extension chargÃ©e la langue dans laquelle elle a Ã©tÃ© chargÃ©e. si pas de i18n, du coup c'est la langue par dÃ©faut Ã chaque fois. Au moins les writers peuvent crÃ©er une nouvelle langue. pas de sÃ©curitÃ© par langue, trop le bordel ! il serait agrÃ©able que seules les extensions demandÃ©es soient chargÃ©es. dans les restore il faut ajouter (extensions, id, + prÃ©chargement d'extensions) attention au moment de la migration au moment du chargement Pseudo extension ================ migration : mÃ©thode migrate(oldExtension, newExtension, Wikitty, Locale) Locale pouvant etre null.

1 0

Maintien des modules non-utilisés ?
by Brendan Le Ny Aug. 6, 2010

Aug. 6, 2010

Certains modules de wikitty sont inutilisés et donc ignorés dans le build par défaut : <module>wikitty-hbase-impl</module> <module>wikitty-jpa-impl</module> <module>wikitty-jms-impl</module> <module>wikitty-multistorage-impl</module> De toute façon, ces modules ne build pas à cause de problèmes de dépendances non résolues. Le build Hudson, quant à lui, essaie de builder tous les modules, et donc le build casse à chaque fois. Je suis en train de faire de gros refactoring sur wikitty et y'a des impacts un peu partout. Du coup, je fait des mvn test avant de commiter mais niveau intégration continue, j'suis à l'aveuglette : comme avec Diswork... Donc faudrait décider - soit les modules doivent être maintenus, dans ce cas il faut régler les problèmes de dépendances pour Hudson et pour les devs de wikitty (moi en ce moment) - soit on décide de ne plus les maintenir, dans ce cas il faut que Hudson n'essaie pas de les builder, voire qu'on supprime les modules Brendan.

4 4

Modification de la generation des entites metier
by Benjamin POUSSIN Aug. 2, 2010

Aug. 2, 2010

Salut, Les champs static des noms des champs des extensions ont ete renome. Donc avant de lancer une recompilation avec regeneration avec la version trunk de wikitty. Je vous suggere d'utiliser vos outils moderne pour faire du refactoring de masse. - aller dans le code genere de chaque interface des objets metier - demander a renomer le champs en utilisant celui qui sera utilise apres la nouvelle generation (votre super outil doit (sinon ce n'est pas un super outil :)) renommer partout ou il est utilise dans vos projets ouverts - modifier dans le pom.xml pour utiliser la nouvelle version wikitty - relancer une generation - tout devrait compiler et refonctionner normalement Voila, je pense que c'est le plus simple/sur/court. Sur ce bon week-end -- Benjamin

2 1

Ajout des modules client/serveur hessian
by Eric Chatellier July 30, 2010

July 30, 2010

Bonjour, Les modules clients/serveur hessian doivent être terminé et testable dans wikitty-ui-zk. La documentation est disponible ici : http://maven-site.nuiton.org/wikitty/hessian.html Cordialement. -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 0

Erreur lors de la suppression de wikitty déjà supprimé
by Eric Chatellier July 29, 2010

July 29, 2010

Bonjour, Sur le projet sur lequel je travail actuellement, il arrive que la base de données se retrouve dans un état incohérent (car les contraintes sont gérées à la main). Lorsque qu'on l'on veux supprimé des wikitty déjà en état de suppression, wikitty lance une exception : Impossible de supprimer un wikitty déjà supprimé !!! Ne pourrait-il pas juste afficher un warning, et retourner un booléen (ou un nombre) pour avoir le réel état de suppression ? Ou est-ce plutôt a l'appelant de le gérer ? -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 1

Problème de manipulation des wikitty avec le cache
by Eric Chatellier July 27, 2010

July 27, 2010

Bonjour, Lorsque l'on récupère des wikitty mise en cache, et qu'on les modifie, ce sont les même instance que celle du cache. Donc si on annule une modification et qu'on restore un wikitty caché, on obtient celle modifié. Quelle est la bonne méthode pour résoudre cette problématique ? - faire une copie du wikitty et ne pas modifier le cache tant que le store n'a pas été appelé ? (à la charge de l'application) - que le cache renvoie une copie (avec les soft référence, ce n'est pas possible je pense) Merci. -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 1

Code non compris lors de la sauvegarde des wikitty
by Eric Chatellier July 26, 2010

July 26, 2010

Bonjour, J'ai un probleme sur lexman, sur une différence de code entre la version jdbc et hbase, plus précisément sur le code : http://www.nuiton.org/repositories/entry/wikitty/trunk/wikitty-jdbc-impl/sr… Lors de la sauvegarde, seulement dans la version JDBC, la liste des extensions est modifiée (pour mettre la dernière version). Le commentaire de commit dit: wikitty-api: enable to restore wikitties whose extension version is not uptodate wikitty-jdbc: change to last extension version when storing wikitties (this enables you to see changes you have just made) Je pense que ce code ne doit être fait que lors du restore (par migration) et pas à la sauvegarde. Le code semble-t-il correct ? -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

2 1

Code non compris lors de la sauvegarde des wikitty
by Eric Chatellier July 26, 2010

July 26, 2010

Bonjour, J'ai un probleme sur lexman, sur une différence de code entre la version jdbc et hbase, plus précisément sur le code : http://www.nuiton.org/repositories/entry/wikitty/trunk/wikitty-jdbc-impl/sr… Lors de la sauvegarde, seulement dans la version JDBC, la liste des extensions est modifiée (pour mettre la dernière version). Le commentaire de commit dit: wikitty-api: enable to restore wikitties whose extension version is not uptodate wikitty-jdbc: change to last extension version when storing wikitties (this enables you to see changes you have just made) Je pense que ce code ne doit être fait que lors du restore (par migration) et pas à la sauvegarde. Le code semble-t-il correct ? -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 0

[ANN] - Wikitty 2.0 released
by nuiton.org Release Notification July 21, 2010

July 21, 2010

1 0

Migration eugene 2
by Eric Chatellier July 8, 2010

July 8, 2010

Bonjour, Wikitty a migré sur eugene 2. Une mise à jour des configuration de génération des projets utilisant wikitty 2.0-SNAPSHOT est donc nécéssaire. Cordialement. -- Éric <chatellier(a)codelutin.com> Tel: 02 40 50 29 28 http://www.codelutin.com

1 0