On Mon, 30 Apr 2012 10:45:55 +0200 Florian Desbois <fdesbois@codelutin.com> wrote:
On 27/04/2012 11:38, Florian Desbois wrote:
Il y a deux solutions : - soit on part comme ca, la sécurité vérifie uniquement le jeton (en dehors d'un admin) et les liens doivent tous être correctement construit suivant les cas => les liens seront valides si non connecté. - soit on rajoute un filtre pour vérifier si l'utilisateur connecté a un accès à la page (via un pollAccount). Dans ce cas les liens peuvent rester simples, la sécurité se charge de vérifier l'utilisateur connecté non administrateur => les liens ne seront pas valides si non connecté.
Après discussion avec Tony, on part sur la 1ère solution. Pas de rajout de sécurité par rapport à l'utilisateur connecté mais création de tous les liens correctement en fonction des contraintes. Ces liens seront toujours valides et cohérents quelque soit le contexte de connexion.
Je me demande pour les sondages créés si on ne devrait pas rajouter un lien pour la page de vote. On a : - celui sans accountId pour un sondage libre et - celui pour un sondage restreint avec creatorId : lien de modération qui ne permet pas de voter et donc ne doit pas être diffuser.
Pour un sondage libre on aurait les deux liens, alors que pour un sondage restreint seul celui de modération est disponible. Il faudrait une nouvelle icône pour éviter les problèmes de confusion avec le lien de modération (qui ne permet pas de voter), probablement une enveloppe avec une petite clé à molette. (EVO #196 : http://chorem.org/issues/196)
Problème avec le système implanté :( ------------------------------------ Au final le système implanté ne fonctionne pas bien car on arrive à des cas pas normal. Je pense qu'il faut tenir compte de tout (accountId dans l'url ou utilisateur connecté) sinon cela ne va pas. Le fait d'essayer de chargé un PollAccount dans l'action de vote ne va pas car le créateur du sondage a un PollAccount mais il peut aussi très bien voter --> autre PollAccount. De plus je vois dans les actions que les règles de sécurité viennent des fois de la couche service, et des fois hardcodé dans l'action ce qui est à proscrire. De plus certaines règles ne tiennent pas compte de tous les paramètres parceque dans l'ui le cas ne peut pas se présenter donc on écrit des règles de sécurité dirigés par l'ui ce qui est un non sens selon moi. Je vois ce genre de code dans une action : public boolean isDeleteVoteAllowed(Vote vote) { // can delete a vote if admin or poll creator return isUserAdmin() || isCreatorUser(); } Comment changer ça ------------------ - Avoir un service transverse de sécurité qui centralise toute demande de droits. - A terme ce service sera remplacé par les permissions via shiro et donc les méthodes de ce service vont permettre de définir les permissions ;). -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com