Discussion :

[adeltimple]

Bonsoir.
j'ai beaucoup cherché notement ici:
http://www.developpez.net/forums/d89...roits-avances/

Mais ça ne colle pas à mon soucis:
j'ai des USERS qui sont répartis dans des profils utilisateurs.
suivant leur profils ils peuvent, ou non, faire des actions.

Par exemple Paul est dans le profil "rédacteur" il a le droit à modifier ses publications, il peut ni supprimer ni modifier celle d'un autre redacteur.

Jeanne, est chef de la redaction elle est dans le profil "Administrateur rédaction", peut supprimer une publication d'un redacteur.


donc dans la table droits, je peut en avoir beaucoup.
comment dois-je gérer ça??

j'ai pensé à 2 solutions:
première: passer par les variables sessions: retranscrire les droits pour ce user dans des variables sessions. mais le soucis est que si j'ai 600 droits, ça me fait 600 variables sessions....

seconde: passer par la BdD systématiquement: à chaque recherche de droit passer par une fonction qui génère une requete SQL pour aller chercher la valeur pour le droit demandé et le user passé en paramètre.


Je bute totalement.
Les 2 ont d'immsensent défauts: la première va ralentit le serveur par des énormes variables sessions, la seconde va mettre du temps à afficher les pages car requete pour savoir si oui il peut éditer cette publication, si il peut en creer une...

Qu'en pensez-vous??
Merci de votre aide

[sabotage]

Tu exagères les inconvénients de chaque méthode :
- pour la premiere, avoir beaucoup de variables en session ne ralentit pas le serveur.
De plus tu nous décris 2 droits différents qui doivent couvrir pas mal de tes utilisateur, en quoi consistent les 598 autres ?

- pour la seconde interroger une base de donnée pour lire un résultat c'est 1/10 de secondes peut être.

D'après ce que tu nous décris je vois de toute facon :
1 - lecture d'un article
2 - l'utilisateur connecté (information en session) est le propriétaire de l'article (fourni par la requete précédente) ou a les droits d'administration (information en session) ? il peut modifier l'article.

[adeltimple]

Tu exagères les inconvénients de chaque méthode :
- pour la premiere, avoir beaucoup de variables en session ne ralentit pas le serveur.

ben il me semble que les variables sessions sont en fait dans un fichhier texte, non?

De plus tu nous décris 2 droits différents qui doivent couvrir pas mal de tes utilisateur, en quoi consistent les 598 autres ?

d'autres exemples:
Pouvoir déplacer une actualité de la catégorie "Bateau" à la catégorie "Moto"
Pouvoir créer une catégorie d'actu
Pouvoir créer une partie / sous partie dans l'architecture des pages
Avoir le droit de désactiver / activer les actualités
Avoir le droit d'utiliser les cookies à la connexion ( j'interdis pour les admin par exemple car sa réduit le risque de massacre par un éventuel con récupérant le cookies )
....

- pour la seconde interroger une base de donnée pour lire un résultat c'est 1/10 de secondes peut être.

Oui mais j'en suis déja à 18 requêtes sur la page.... ( à noter que je suis en phase de développement et non d'optimisation, et aucune requête n'est en cache pour l'instant )

D'après ce que tu nous décris je vois de toute facon :
1 - lecture d'un article
2 - l'utilisateur connecté (information en session) est le propriétaire de l'article (fourni par la requete précédente) ou a les droits d'administration (information en session) ? il peut modifier l'article.

Oui c'est une solution donc je créé des variables sessions??

Peut-être pas forcément la meilleure solution.

mais étant donné la multiplicité de droits,
bien que je ne sache pas comment il se répartissent
il serait pas trop mal de les regrouper en hiérarchie.

- lecteur
- droit de lire
- droit de poser une question
-rédacteur
- droit d'écrire
- droit de supprimer
-tout le monde
- droit commun à tout les utilisateurs

comme ça tu gagnes en variables à la connexion de l'utilisateur
l'utilisation de session est intéressante en effet à mon idée
et tu découpes tes ajouts de variables de session en fonctions pour plus de clarté.

si vraiment ça risque d'imposer une importante sollicitation du serveur, pourquoi ne pas utiliser un temporisateur de sortie ? ( fonction php ob_start() )

voilà mon idée !

les ob_start et ob_end_flush je les utilisent déja et le script pour récupérer les droits sera dedans.

Donc en résumé je pars en utilisant les variables sessions, quitte à en avoir 600, en essayant d'organiser mes droits au mieux? ( la hierarchie )

Un grand merci pour votre aide

[adeltimple]

je vous communique ma solution: on vas passer par les bits....
si je me souviens de mes cours elle respecte normalement MERISE

1 table USER ( contenant les infos )
1 table PROFIL ( contenant l'id et le nom du profil )
1 table MODULE ( elle contient des infos car mon site est du type: un noyau et des modules )
1 table AVOIR_PROFIL_MODULE ( en gros c'est une personnalisation qui contient l'id du profil et l'id du module et l'id du droit )
1 table DROITS

Cette table contiendra un ID et une valeur pour le droit sous forme de binaire:
par exemple pour le module "gestion de contenu"
11111 tout les droits= super administrateur
00001 ne peut qu'éditer sa propre édition et est soumis a autorisation = éditeur
00101 ne peut qu'éditer sa propre édition et celle des voisins et est soumis à validation
00111 ne peut qu'éditer sa propre édition et celle des voisins mais pas soumis à validation

[greg59166]

Peut-être pas forcément la meilleure solution.

mais étant donné la multiplicité de droits,
bien que je ne sache pas comment il se répartissent
il serait pas trop mal de les regrouper en hiérarchie.

- lecteur
- droit de lire
- droit de poser une question
-rédacteur
- droit d'écrire
- droit de supprimer
-tout le monde
- droit commun à tout les utilisateurs

comme ça tu gagnes en variables à la connexion de l'utilisateur
l'utilisation de session est intéressante en effet à mon idée
et tu découpes tes ajouts de variables de session en fonctions pour plus de clarté.

si vraiment ça risque d'imposer une importante sollicitation du serveur, pourquoi ne pas utiliser un temporisateur de sortie ? ( fonction php ob_start() )

voilà mon idée !