Salut, Voila un début de réflexion pour l'ajout de la securite: On continue sur l'idée de couche de service basé sur l'interface WikittyService. Actuellement nous avons: - WikittyServiceImpl (qui fait réellement le travail) - WikittyServiceNotifier (pour le super des listeners et la distribution des events) - WikittyServiceCached (pour ajouter du cache distribué ou non si on a aussi le notifier) On ajoute les methodes suivantes sur le WikittyService: - login(String login, String password):String // return token - logout(String token); Toutes les methodes du service prennent en 1er argument un token. S'il est vide ou invalide (forgé) on considère que l'utilisateur n'est pas logguer et donc n'a accès qu'aux ressources qui ne nécessitent pas de droit. Je préfère que le token soit le 1er argument plutôt que d'imager des choses magiques comme l'envoi grâce au protocole de comm ou autre astuce, qui sera difficile a mettre en place, à porter sur les différents protocoles, à maintenir et à comprendre pour les utilisateurs. Authentification ================ ajout dans le proxy: - login(String login, String password):String - logout(); - setToken(String token) - getToken():String Le token est conservé dans le proxy pour que l'utilisateur n'est pas a le stocker dans son application, ni à le passer aux méthodes du proxy. Mais cela veut dire que le proxy n'est plus mutualisable entre plusieurs utilisateurs, mais reste threadSafe car le token n'est qu'en lecture dans 99% du temps. Pour pallier a la non mutualisation du proxy entre different utilisateur et si l'instanciation d'un proxy est couteux, on pourra mettre en place pour les applications web un pool de proxy. Autorisation ============ Si pas de sécurite d'activée tous les objets sont dit annonyme. Cela peut aussi arriver si la personne n'est pas authentifiée. Sinon, la sécurite ajoute automatiquement aux nouveaux objets l'extension WikittyAuthorisation(owner:WikittyUSer, Admin:List<WikittyGroup>, writer:List<WikittyGroup>, reader: List<WikittyGroup>) Ou owner est fixé à la personne qui à créé l'objet Les objets anonymes ne peuvent avoir l'extension WikittyAuthorisation que si un admin de l'application lui ajoute (les admin sont defini par configuration de l'application) Ensuite pour modifier les champs de WikittyAuthorisation cela peut-etre fait par les admins de l'application et les admins déclarés dans l'authorisation elle même Les modifications de l'extension Authorisation ne sont permissent que côté serveur juste avant l'enregistrement. Un objet autorisation sera aussi lié à l'extension pour savoir qui peut créer ce genre d'extension (il faudra donc lors de la sauvegarde regarde si précédemment l'objet avait cette extension ou non avant et si ce n'était pas le cas, vérifier que la personne a le droit d'ajouter cette extension avant de faire sa sauvegarde. question comment lier une autorisation a une extension ? en utilisant un tag value, un fichier de configuration, ou un autre moyen ? Pour verifier qu'une personne a le droit de faire une action: - pour la création on regarde l'authorisation sur l'extension - pour la modification de l'authorisation on regarde les AdminApp|Admin de l'objet sur la version précédente - pour la modif on regarde les AdminApp|Admin et writer de l'objet - pour la lecture on regarde les AdminApp|Admin, write et readers de l'objet Pour simplifier dans une 1er temps, seul les AppAdmin pourront créer ou modifier les extensions. Il faudra bien faire attention qu'une application n'arrive a pas modifier des droits en modifiant simplement l'objet de son cote et en le sauvant. Nouvelles extensions ==================== - WikittyUser(login(email?), password) - WikittyGroup(name:String, contains:List<WikittyUser|WikittyGroup>) - WikittyAuthorisation(owner:WikittyUSer, Admin:List<WikittyGroup>, writer:List<WikittyGroup>, reader: List<WikittyGroup>) -- Benjamin -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com () campagne du ruban ascii http://www.codelutin.com /\ pour les mails en ascii