Bonjour,
 
  je suis en train de developper une application Intranet basé sur du Web PHP/HTML/JavaScript. Mais j'ai un probleme au niveau de la gestion des droits d'acces.
 
  Voici comment fonctionne l'application :
 -> Elle est basée sur un coeur composé de classes qui possedent des operations contenant des algorythmes.
 -> Les donnees et la mise en forme sont separées.
 -> Cette application est basée sur des modules. Des modules peuvent dependre d'autres modules.
 
 -> Pour les droits d'acces, j'utilise 2 tables de swap :
=> 1 Table de swap foonction/Module qui me permet de savoir quelles fonctions sont autorisées a voir le module
=> 1 Table Utilisateur/Module qui me permet de savoir, si une personne n'appartient pas a une fonction autorisée, de lui donner un droti d'acces.
 
 Mais j'ai un autre probleme : Dans un module, je peux avoir des pages qui peuvent etre utilisées par des personnes/fonctions mais pas par d'autre. Prennons l'exemple d'un Commercial et d'une Secretaire : Dans un module appelé Gestion Documentation, un Commercial peut generer un document, imprimer ou consulter un document. Par contre une secretaire elle ne peut pas generer le document.
 
 Vous voyez ou je veux en venir : quelle est la solution la plus propre pour associer à chaque page un droit d'acces niveau fonction ou utilisateur, sachant qu'une personne ou fonction n'ayant pas le droit d'acces a un module ne pourra pas y entrer.
 
 L'utilisation d'une table de stockage page/utilisateur_id et page/fonction_id me parait un peu lourd, l'utilisation d'un niveau d'acces est mal placé : une secretaire n'a pas plus de droit qu'un commercial et inversement.  
L'utilisation de fichiers texte/XML alourdi le temps de generation
 
Avez vous une idee SVP ? quelle methode dois je appliquer ?

Moi j'avais fait un truc du genre, mais sans utiliser les classes...
 
 
Tu dois avoir une table qui rassemble les différents utilisateurs. A chaque personne, tu attribues un type d'utilisateur, et tu instaures un système de login/mdp.
 
Au moment du login, tu envoie deux variables de cession : le login et le type. Après, avant chaque page, tu fais un truc du genre
 
<?
if( type == "secrétaire" )
  header("Location: pageOuTuLEnvoies.php?parametres" );
?>
 
Voila, c'est peut etre pas le plus simple, mais ca a donné de bons résultats...
Tu peux meme rajouter des bouts de javascript, genre une alerte (MsgBox par exemple).
 
 
 
edit: j'espere que c'est pas troll...

 
Merci pour cette premiere ebauche. Pour le type, c'est pour moi une fonction.
 Mais le probleme est plus complexe : En effet pour cahque page je devrais tester quelle fonction doit etre autorisée, ce qui est ma foi assez difficile a realiser puisque une page peut etre visible certaines fonctions et pas d'autres. Ce qui signifie, a chaque fois que je devrais modifier chacune de mes page pour voir si cette fonction est autorisée ou non. Ce que je peux faire c un tableau associatif page/fonctions mais je ne sais pas si c'est le plus adequat
 
Ce n'est pas un troll, non. Nous ne sommes pas Vendredi

Moi je dirais qu'une table c'est bien, mais je ne suis pas expert non plus ...
 
Voila, je ne sais rien de plus

J'ai une solution mais je ne sais pas si c la plus performante :
 
 J'ai une table qui contient comme colonne :
 identifiant, module_id,nomdepage.php
 
Je mets une contrainte UNIQUE sur module_id et nomdepage.php
 
Je cree une page de swap qui contient :
 identifiant, fonction_id (foreign key)
 
Je met une contrainte primary key sur les deux colonnes
 
Ensuite une table de swap
identifiant, personne_id (foreign key)
 
Je met une contrainte primary key sur les deux
 
Comme ça je sais grace aux deux tables de swap quelles pages sont accesible par fonction et par personne
 
Est ce que c acceptable ?
 
 
Ensuite je pourrais virer les keys pour gagner en perf mais comme je suis dans la phase de dev mieux vaut avoir des contraintes d'integrite fortes...

t'es sur quel sgbd ?

Sur postgres mais le but c de l'etendre ensuite a n'importe quelle BDD d'ou la volonte a la suite de supprimer les contraintes d'integrite : Access et MySQL etant assez pauvres à ce sujet.