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

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]<mailto:[email protected]>>

Le 15 mars 2011 15:52, Jean-Baptiste BRIAUD -- Novlog <[email protected]<mailto:[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 -)

--
[http://www.eclipsecon.org/2011/static/image/friends/100x100_speaking.gif]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.
********************************************************************************