Bonjour tout le monde,
 
je seche un ptit peu pour mettre en place un systeme de gestion de droits.
 
g developpe une application admin pour la societe où je travaille, cette application contient plusieurs modules : gesion du catalogue, news, conferences, clients... et j'aimerais attribuer des droits au personnel.
C'est a dire:
X a le droit de creer et modifier et supprimer le catalogue. consulter uniquement le reste des modules
Y a le droit de creer et modifier et supprimer les news ET le catalogue. consulter uniquement le reste des modules
...
 
Merci enormement de votre aide.
Reda

Quelle est la question?

- champ "droits" dans ta base de données
- tu définis une valeur binaire correspondant à chaque droit. exemple 0001  = creer le catalogue; 0010 = modifier le catalogue ; 0100 = supprimer le catalogue
- tu te sers de ce champ comme d'un masque binaire. Exemple : 0101 = creer un catalogue et le supprimer ; 0110 = modifier le catalogue et le supprimer...
- dans ton appli tu teste les droits de l'utilisateur en faisant un et logique. exemple : pour modifier le catalogue il faut que (0010 & droit_utilisateur) = 0010 ...

ou bien une colonne par droit, ce qui peut lui permettre de lister d'une traite tous les profils ayant le droit de modifier un  catalogue p.ex.

 
T'as rien de plus simple?

Mouai, ou alors un N° permettant d'accéder à certaines pasges, les pages les plus élevées étant celles de l'administration
 
Style 0-20 : pages standards
40-60 : Modérateurs
80-100 : Admin etc... (exemple hein), avec juste un champs, facile à comparer et à utiliser

et créer une table des droits, une table des groupes d'utilisateurs, une table des utilisateurs et une table liant les groupes aux droits ça vous parait trop classique et trop simple à mettre en place et à comprendr epour tout le monde?

Heu... heu... C'est quoi la question ?

La question, c'est pourquoi ils lui répondent de se faire chier avec des calculs à la con pour gérer ses droits???

Utiliser un masque binaire, c'est ni plus ni moins que ta solution en optimisé...
 
T'as différents droits, dont la valeur correspond à une puissance de 2 :
1, 2, 4, 8, 16, etc. (c'est à dire, en binaire 00000001 00000010 00000100 00001000 00010000 etc.)
 
Ensuite, au lieu de faire une table d'association user <-> droit on colles une colonnes numérique "droits" dans la table "user" qui va contenir la somme des droits disponibles. Genre 1 = lecture, 2 = modification, 4 = supression, 8 = création. J'ai un user qui doit pouvoir lire des fichiers et en créer, mais ni en modifier/supprimer : 1 + 8 = 9 = 00001001
 
=> Lorsque je veux savoir s'il peut lire je vais juste faire un test binaire 9 | 1 > 0
 
Donc on économise énormément de place dans la base, et les traîtements sont plus rapides en mémoire.
Mais la solution est rigoureusement la même.
 
Si tu connais CHMOD d'Unix, tu verras que c'est le système utilisé sous Unix pour gérer les droits depuis... 30 ans ?

Un peu plus de détails ici :
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
(et d'autres pistes pour élargir les possibilités offertes)

Super le gain de place.
On va dire 8 niveaux de droits, donc 8 octets avec sa méthode et 1 avec la tienne. Donc 7 octets de différence.
On va dire 15 groupes de personnes + 10 cas personnels le tout multiplié par une disaine de modules et 120 sections de modules.
Au total on arrive au calcul suivant :
(15+10)*(10+120)*7=25*130*7=3250*7=22750 octets
 
C'est cool, ta méthode fait gagner moins de 23ko et pourtant j'ai pris assez large pour la pluspart des sites. En plus de ça, elle oblige à rajouter des calculs pour savoir ce que peut faire chaque personne (même si tu gagnes du temps sur le transfert, ca ne fait pas gagner grand chose) , elle complique certaines requettes (par exemple pour avoir la liste des personnes qui ont un accés lecture seule sur une section donné) et elle empéche une lecture directe des informations (il faut penser que lecture+écriture = 3 ou 7 ou 15 ou ...) .
 
Finalement, ta solution, c'est un peu de l'enculage de mouche façon base de donnée.

Excuse-moi, mais les masques binaires ça vient pas trop des SGBD au contraire (y'a pas de masque binaire dans la norme SQL hein...)
 
Par contre t'as jamais entendu parler des "flags" sur un CPU par exemple ? Bah c'est bête, c'est justement ce fonctionnement.
 
Ca n'a rien d'un enculage de mouche, c'est au contraire la base même de la prog.

 
+1
 
D'autant que le calcul de place de omega2 me parait complètement foireux : il faudrait prendre en compte la taille des tables (pas forcement le même nombre de champs, pas les mêmes types), la vitesse des requetes puis la mémoire occupée et le temps de traitement côté applicatif (disons php).

Merci pour l'info...
 
En attendant, dans le contexte de la question, c'est complètement crétin. L'économie de place est absolument ridicule, et est loin de contrebalancer la perte de lisibilité des données elles-mêmes, et des requêtes à générer.
 
Le mec qui me fait ça dans une base application web je lui fais recommencer le tout sous la menace d'une pelle à clous...

Perso, le coup des masques binaires (comme pour les droits unix) c'est bien quand tu as seulement qq droits à gérer. Mais quand tu en as plusieurs 10ènes, ça va pas être facile à administrer simplement avec PhpMyAdmin. Il te faut obligatoirement une IHM qui te décompose en flags le nombre entier correspondant aux droits de l'utilisateur.
ex : 25522766 -> au premier coup d'oeil, c'est pas évident de savoir les droits associés à l'utilisateur qui un tel nombre comme droits d'accès
 
Donc, je dirais que techniquement, c'est une bonne solution, mais, d'un point de vue humain, c'est pas facile à administrer manuellement sans outil. Donc, je pense que d'avoir une table avec une colonne par droit me paraît plus approprié En +, si tu viens à rajouter un nouveau droit, bonjour le rétrofit de la BD ou alors, faut placer le nouveau droit au début du nb Alors, qu'avec les colonnes, ben on en ajoute une avec une valeur par défaut...Comme ça, pas de pb.

Ba tout dépend de l'utilité de la gestion de droit (accés à des pages? personnalisation des autorisation dans la back office etc..), du nombre de personnes y ayant accés, ... en bref tout est concevable., et puis nivreu lisibilité, un 0110 binaire, est autant lisible que n'importe quoi d'autre.

Aux dernières nouvelles chmod c'est pas un sgbd

• La signification du champ devient totalement opaque: on est obligé de passer par la doc ou (encore pire) par le code de l'appliquation pour comprendre quels droits sont gérés par le bitmask et sous quelle structure

• Le design de la DB et l'implémentation du programme deviennent irréversiblement liés ce qui est une grande source d'amusement si on doit un jour utiliser la DB dans une autre app

• Impossible de mettre en place des contraintes d'intégrité simples, si on veut en générer c'est la fête au trigger

• On perd énormément en évolutivité, si on doit e.g. ajouter un certain nombre de rôles on peut se retrouver dans l'obligation de refaire nombre de tables et de procédures associées, si on gère les droits de manière normalisée classique ce problème n'existe pas

Voir http://www.dbdebunk.com/page/page/622161.htm pour une critique plus complète de l'utilisation de bitmasks pour la gestion des droits dans une db

En conclusion, utiliser un bitmask peut avoir un sens si on se rend compte que la gestion des droits est bloquant au niveau des performances de l'appli (et j'ai comme un doute), mais ça n'a strictement aucun sens en tant que schéma par défaut.

cgo2 > Quand on à une table de droit de 50ko, (soit l'équivalent aproximatif de 22ko de données si on compte les index et la place prise par la structure d'une table) on a généralement une base de plusieurs disaines ou centaines de mégas. C'est trés rare qu'une table de droit prenne autant de place avec juste quelques mega de donnée. D'ailleurs, ca correspondrait à plus d'une déclaration de droit par discution ouverte sur un forum par exemple.
Donc oui, je confirme mon avis, c'est de l'enculage de mouche comparé à toutes les autres optimisations possible au niveau des bases de données. En fait, c'est du même niveau d'optimisation que le coup du "case" Vs "elseif" en php.
 
PS : A part pour des cas rare du genre "je peux créer une discution mais je ne peux jamais répondre", dans quel cas un systéme de flag est utile? A mon avis, ca n'est pas trés utile de dire "tu peux modifier mais pas voir" (super, on modifie en aveugle maintenant?) ou "tu peux modérer mais tu ne peux ni voir ni modifier" (il fait comment pour modérer du coup? Il clique au hasard en espérant tomber juste?)
 
EDIT : je voulais dire "par discution ouverte sur un forum " et non "par message posté sur un forum "

Moi je suis plutôt d'accord avec Magicbuzz (et en plus, il a l'air d'avoir de l'expérience là-dessus, plutôt que de sortir des exemples du net). En plus, on peut facilement créer des access control list avec les chmod.

Par exemple, on crée un système de fichiers virtuel en bdd, avec des droits associés.

C'est puissant et extensible. Je sais pas ce que vous n'arrivez pas à comprendre...

Heuu même ça ya pas besoin de bitmasks pour le faire, le bitmasks c'est juste une représentation pour la sérialisation des droits en DB, ça fait pas de magie

 
J'ai vu l'erreur de ma voie, je suis d'accord avec Lam's en fait

 
question bête : et si ton serveur web est sous windows?    

attendez encore 8h51 pour troller

Ha mais on a bien compris que c'est extensible. Là n'est pas le probléme.
 
En fait, on peut trés bien vous retourner la pareille : qu'est ce que vous n'arrivez pas à comprendre quand on vous dit que c'est pas souvent la solution idéale?
 
Quand à magicbuzz, il a de l'expérience, mais je pense que du haut de mes 7 ans d'utilisation intensive des bases de données et d'un certain nombre de langages j'en ai autant que lui sur ce genre de point.
D'ailleurs, s'il suffisait d'avoir de l'expérience pour avoir la science infuse, ca se saurait et on ne serait pas là à discuter de ça.
 

C'est vrai, a force de modifier mon message pour éviter de dire de grosses conneries, j'en ai laissé une énorme en ne virant pas ce bout là alors que j'avais viré ce qui allait avec.

N'importe quoi t'as rien compris du tout gros naze

Je ne suis pas un troll, je suis un expert en développement informatique, avec plusieurs années d'expérience dans le développement logiciel hétérogène comme Php, C, Visual Basic Edition Applications, et j'ai même fait un projet à l'école en Assembleur 80286.
 
Ce n'est tout de même pas de ma faute si vous ne maîtrisez pas les droits façon Linux, ou si vous ne savez pas compter en binaire.

C'est censé être incompatible?

Lol, je t'éclate mec, des projets en environement hétérogénes, j'en ai fait dés mes études. C'est d'ailleurs classe de voir du PERL et des script shell réagir à d'autres langages.
 
Derniérement, j'en ai fait un petit pour tester les intéractions entre du .net du php et du java sous systéme unix. Aller qui dit mieux?

Bonjour a tous
 
je vous remercie infiniment pour toutes vos reponses.
 
la solution du binaire me parait bien mais ca reste en tout ptit peu flou ds mon esprit:
001 : lecture
010 : ecriture
100 : suppression
...
 
ceci je l'ai bien compris.
mais cmt faire pour adapter cette methode lorsqu'on doit l'appliquer sur plusieurs partie du site???
 
l'idee que g est de creer une colonne pour chaque module du site avec les valeurs:
w : ecriture
r : lecture
d : acces refuse
sachant que 'w' peut etre en lecture biensur
 
qu'en pensez vous?

Mettre "D" pour accés refusé est une mauvais idée, il vaut mieux ne rien mettre, ca sautera aux yeux plus facilement comme ça.

le - s'y prête bien (cf droits unix) pour accès refusé (absence de droit).

Interessant, même si je ne suis pas d'accord avec tous les arguments, c'est vrai que je n'avais jamais abordé ce problème *spécifiquement* dans le cadre d'une db.

Du coup je me demande : avec la méthode sans bits, comment faire pour gérer simplement une dépendance des permissions ? Par exemple si "modifier un message" implique de pouvoir "lire un message". Avec les bits, j'utilise une solution toute simple : "lireun message" vaut 1, "modifier un message" vaut 3 ('11' en binaire), c'est à dire qu'il utilise aussi le bit "lire un message". Y a-t-il là aussi une solution "normalisée" ?

cf le lien que j'ai mis tout à l'heure, dans lequel j'étais parti dans une application du système plus complexe, pour reproduire notamment les ACL de la NTFS par exemple.
 
ensuite, je suis d'accord avec omega2, en nuançant. je trouve que les masques binaires ne sont pas illisible à condition d'être documentés.
 
le meilleur exemple, c'est l'ERP avec lequel je travaille. il y a une table "calendrier", avec des codes calendriers, et une colonne par mois. dedans, on a à chaque fois un int32 quelque peut... étrange.
 
en l'absence de documentation, je suis parfaitement d'accord pour dire que c'est imbittable.
mais une fois qu'on sait que le bit0 c'est le premier jour du mois, et le bit30, le 31ème, qu'un 0 signifie "pas d'info" et 1 "info", on repère très aisément les jours fériers dans un mois, et ce, sans lire une floppée de tables, sans avoir 30 lignes de résultats, etc.
 
après, rien n'empêcherais de faire la même chose avec une table détaillant jour par jour. perso, je ne vois pas de différence majeure, mise à part un gain de place et une optimisation certaine de l'utilisation de la base.
 
niveau lisibilité, ça dépend surtout de si on a l'habitude ou non de la chose.
 
il y a quelques temps, un techos de ma boîte de requêter dedans. il comprends rien. il appelle mon patron, qui pige rien. ils appellent l'éditeur, pas foutu d'expliquer (lol). ils appelle quelques connaissances pas moyen de comprendre ces nombres. ils finissent par me tomber dessus "ben... z'êtes cons les gars, c'est un masque binaire... "

Quand la lisibilité du code dépend de l'habitude, je pense que ça a de grandes chances d'être de la merde. Après c'est variable suivant le langage, mais ça reste de la merde quand même.
 
Qu'est-ce qui est le plus coûteux ? Temps machine ou jours/homme ?
Quand je vois le temps de développement perdu à comprendre des mécanismes non-triviaux qui sont là pour gratter quelques octets et quelques millisecondes qui ne s'imposaient pas...
Quand bien même les mécanismes ont été documentés, la documentation doit être claire, complète, à jour et facilement accessible (cad indexée correctement, et à un endroit connu de ceux qui en ont besoin. C'est trivial mais pourtant...).
 
Alors qu'un schéma proprement fait, avec des contraintes clairement définies...

COMMENT MaTable.MonMasque IS 'Ce champ est un masque binaire qui se lit de droite à gauche';

 
10 secondes chrono, et plus rapide à appréhender qu'un left outer join permettant de récupérer la liste des jours non fériers alors qu'une table de relation ne contiendrait que les jours fériers
 
Je suis d'accord en partie avec ce que tu dis cependant, mais là, le coup du masque binaire, c'est quand même un truc qu'on utilise en permamance en programmation... Quand tu passes des "flags" ou que du les récupère d'une API, quand tu vas contrôler le résultat d'une dialog box, quand tu vas paramètrer le type de curseur à ouvrir sur ton SGBD... Tu passes temps temps à faire des masques !

COMMENT MaTable.MonMasque IS 'Ce champ est un masque binaire qui se lit de droite à gauche';

Je ne vois pas en quoi cet argument abonde dans le sens de l'utilisation de masques binaires pour gérer les droits d'accès.
On est quand même dans un cas d'utilisation assez précis. Je ne vais pas prétendre que les masques binaires c'est le mal absolu. Néanmoins, une table contenant toutes les permissions est une solution propre, extensible facilement, autodocumentée.

D'autant plus qu'il est possible de lire les droits d'accès en une seule fois (souvent au login de l'utilisateur), ce qui rend la question de leur performance caduque. A moins d'implémenter une gestion extrèmement complexe, il n'y a pas énormément de jointures.

MagicBuzz > Donc les flags sont trés utilisé dans les API systémes et certaines API ou parties d'API où l'optimisation du temps CPU est primordial. Mais quel rapport avec un stockage sous forme de flags? Serais tu entrein de dire que par ce que c'est primordial dans certains cas, ca doit être une forme de stockage à utiliser dés que possible?
 
Tu parles aussi d'un cas de calendrié. Mais dans le cas que tu cites, le stockage sous forme de masque binaire limite de lui même les capacités du calendrié. A moins de stocker une ligne par année/pays/cas normal et spéciaux (la bourse par exemple) le calendrié se révéle incomplet et faux vu que certains jours fériés changent de date chaque année.  
 
De plus avec 31 "0" et "1" qui se suivent, je pleins le gas qui est censé faire une vérification à la mano. Ca doit être chiant de vérifier que c'est bien le 14 éme chiffre qui est un 1 et pas le 15 éme. Même si l'ensemble est trés bien documenté, ca reste quand même une donnée trés dure à lire sans le programme qui va bien. Si c'est comme pour certains ERP, j'aurais les boules de perdre 10 à 15 minutes le temps de lancer l'ERP et d'atteindre la bonne fiche alors que je l'aurais corrigé en 15 secondes avec une base conçu différement.
 
EDIT : Message refait en plus clair.
EDIT 2 : fausse manip, j'ai rippé sur la case qui "supprime le message" d'où un nouveau message.

Douleur Intestinale > Mon argument n'abonde pas dans le fait qu'il faille utiliser ou non des masques. Je dis juste que perdre 10 secondes à documenter ce qu'on fait permet d'éviter de faire perdre du temps à ceux qui passent derrière, quelque soit la méthode utilisée.
 

En aucun cas, je dis juste que les masques binaires, c'est du quotidien pour un développeur, et il n'y a rien de choquant à travailler avec, contrairement à ce qui a été dit plus haut.
 

C'est pas plus limité que d'avoir une table listant tous les jours fériers sous forme de lignes... Là faut que tu m'expliques en quoi une solution est plus limitée que l'autre... Au contraire (exemple tout à l'heure à l'appui, sous forme de lignes c'est plus limité)
 

La vérification à la mano est pourtant très simple (calculs entiers)...
(val mod 2^x) / 2^(x-1) = 1
 
 
Sinon, exemple d'une table CAL avec masques :
ANNE int16
CODE char(3)  [FER/VAC/INV/...]
JAN int32
FEB int32
MAR int32
APR int32
MAY int32
JUN int32
JUL int32
AUG int32
SEP int32
OCT int32
NOV int32
DEC int32
 
Je veux savoir si le "08/06/1958" était férier ou non ?

SELECT (mod(decode(month(madate), 1, jan, 2, feb, 3, mar, 4, apr, 5, may, 6, jun, 7, jul, 8, aug, 9, sep, 10, oct, 11, nov, 12, dec), pow(2, day(madate)) / pow(2, day(madate) - 1) ferier
FROM cal
WHERE annee = year(madate)
AND code = 'FER'

 
C'est pas la mort non plus hein...
Mais surtout, au lieu de faire tous les calculs dans le SGBD (qui n'est pas optimisé pour -sauf certains, SQL Server 2005 a tout ce qu'il faut pour faire des masques binaires par exemple-) j'ai juste à lire les 12 entiers et les traîter dans mon programme en utilisant de réels masques binaires... Rapide, simple et efficace.
 
Maintenant, la solution des tables :
 
JOUR datetime (déjà, on utilise un float64, c'est bien parti)
CODE char(3) [FER/VAC/INV/...]
FLAG byte (8 bits de plus)
 

SELECT flag
FROM cal
WHERE jour = madate -- avec tous les risques si madate = '08/06/1958 12:31:59' => ça marche plus !
AND code = 'FER'

 
=> plus simple au premier abords...
 
Sauf que par souci d'optimisations, on va rapidement être tentés de ne maquer que les lignes où flag = 1, c'est à dire "fermé".
Effectivement, là où la solution des masques, c'est 1 ligne de 14 champs par type de calendrier et par année, on se retrouve ici avec 365 lignes de 3 champs par type de calendrier et par année, ce qui peut rapidement s'avérer conséquent.
 
Du coup, on va faire :

SELECT top 1 flag
FROM (
SELECT flag
FROM cal
WHERE date = madate -- avec tous les risques si madate = '08/06/1958 12:31:59' => ça marche plus !
AND code = 'FER'
union
SELECT 0 FROM dual
) tmp

 
Ca se complique...
 
Mais surtout, le jour où personne n'a initialisé la table pour une période donnée, on ne sait pas détecter si c'est ouvert ou non renseigné...
Si je veux récupérer tous les jours ouvrés d'un mois, je dois faire un test qui n'utilise plus d'index, ce qui va devenir emmerdant surtout si j'ai de nombreux calendriers en base.
 
 
Bref, je cherche pas à démontrer quoi que ce soit. C'est juste qu'un choix ne s'impose pas sur l'autre. Pour un calendrier, je trouve ça plus pertinant de travailler avec un masque.