Re: Chacun dans son dossier, comment feriez-vous ?

En fait, plus j'y pense, plus je m'oriente donc vers des tables de gestion des droits, à la file system.
J'ai l'impression qu'en pensant astucieusement les colonnes des droits, on pourrait gérer des arbo avec des notions de groupes ...
A affiner ... mais je ne pourrais pas utiliser des solutions qui ne stockent pas les données dans une base classique.


On 15 mars 2011, at 16:10, <[email protected]> <[email protected]> wrote:

> Bonjour,
> J’y vais de mes 2 euro-cents aussi :
> Un tel système ne gère pas facilement des droits sur une arborescence complète de documents malheureusement.
>  
> Avant de trasher le message que j’étais en train d’écrire j’imaginais une solution à la file-system.
> Mais j’ai pas mieux à proposer que  JCR déjà suggérée ;-)
>  
> Patrice
>  
> De : Laurent Forêt [mailto:[email protected]] 
> Envoyé : mardi 15 mars 2011 16:06
> À : jerome moliere
> Cc : java
> Objet : Re: Chacun dans son dossier, comment feriez-vous ?
>  
> Je trouve comme les logs que la gestion des droits est un super Use case pour de l'AOP inteception à chaque usage d'un document. De plus  mes droits je les stockerai dans une seule table (idUser/idRole , iddoc, ReadWrite) pas de jointure.
>  
> my half a cent.
>   
> Laurent
> 
> 2011/3/15 jerome moliere <[email protected]>
>  
> 
> Le 15 mars 2011 15:52, Jean-Baptiste BRIAUD -- Novlog <[email protected]> a écrit :
>  
> Bonjour,
> 
> Comment implémenteriez-vous une séparation à l'échelle de la données ?
> Je m'explique : avec les rôles associé à des login, on peux restreindre un accès aux données.
> Sauf que cette restriction porte plutôt sur des "pans applicatif", des fonctionnalité.
> 
> Comment aller jusqu'à la données ?
> Un exemple : chaque responsable de département ne peut voir que son département.
> 
> un autre : chaque collaborateur ne peut voir que son dossier.
> Il faut donc bien qu'un collaborateur avec ses rôles puisse accéder aux dossiers en terme de classe/table.
> Sauf que pour les dossiers id 12 et 13 seulement.
> 
> Là où çà deviens amusant, c'est que des personnes peuvent changer de poste et devenir responsable de département.
> Les restrictions sont donc forcément dynamiques.
> 
> On peut créer des dossiers et on affecte des utilisateurs ...
> 
> Pour l'instant, j'imagine pour une table T concernée (T = le dossier par exemple)
> une table de restriction faisant la jointure entre qui à la droit à quoi : disons une table RT avec 2 colonnes : l'id T et id de l'utilisateur.
> 
> Ca fait pas mal de table en plus, pas mal de données en plus : imaginons une table à forte volumétrie, ce genre de contrôle va être consommateur en ressource ...
> Surtout qu'on peux aussi imaginer une gestion plus fine : lecture, modification, ...
> Est-ce que çà doit finir comme une gestion de permission type file system mais en base ?
> 
> Ah oui, je précise : c'est tout des tables dans une base de données relationnelle et des classes grâce à OpenJPA.
> 
>  
> salut jean Baptiste,
> je vais me positionner à l'echelle 7 comme Tchernobyl en niveau de risques, mais cela devrait rappeler des trucs à Tania quand elle était jeune et belle non? -)
> cette digression mise à part je pense que cela doit pouvoir te rappeler 2 D.P bien connus:
> - le proxy
> - le decorateur 
>  
> en gros tu t'occupes pas des droits sur ton accès JPA et après tu filtres avec la politique idoine
>  
> my 2 cents
> Jerome
> PS:
> certes c'est un peu bourrin -) 
> 
> -- 
> J.MOLIERE - Mentor/J
> auteur Eyrolles
>  
>  
>  
> ********************************************************************************
> IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
> et peuvent etre protegees par la loi.
> Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
> Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
> et tous les fichiers eventuellement attaches.
> Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
> Tout message electronique est susceptible d alteration.
> A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
> De meme, il appartient au destinataire de s assurer de l absence de tout virus.
> 
> IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
> intended only for the named recipient(s) above.
> If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
> Any unauthorized view, usage or disclosure ofthis message is prohibited.
> Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
> Additionally the recipient should ensure they are actually virus free.
> ********************************************************************************