Discussion :

[Choucwoot]

Bonjour,

Je travaille actuellement sur un projet symfony dans lequel je souhaite utiliser le plugin SfGuard pour restreindre l'accès à certaines pages à certains utilisateurs.
Pour faire simple, les utilisateurs ont des company et un utilisateur loggué ne peut accéder que aux pages qui concernent sa company.
J'ai donc pensé à une table User possédant une relation One-to-many avec une table company (un utilisateur n'a qu'une company) et qui hériterait de la table sfGuardUser (type d'héritage concrete). Il faudrait donc que le formulaire de sign in du plugin SfGuardUser aille chercher les user non pas dans la table SfGuardUser mais dans ma table User personnalisée. Cela est il possible, sachant que j'ai vu que je pouvais également utiliser la table sf_user_profile pour ajouter une relation entre les tables company et sfGuardUser mais la première solution me semble plus claire.

Merci d'avance,

Choucwoot

[Michel Rotta]

Tu as plusieurs solutions.

Celle que tu envisages est bonnes. Par contre ta descriptions du liens entre user et compagny n'est pas claire, tu dis : "les utilisateurs ont des company et un utilisateur loggué ne peut accéder que aux pages qui concernent sa company" ce qui laisse entendre dans la même phrase qu'un user peut avoir plusieurs compagny mais n’accéder qu'à une...

Le fait de faire un héritage permet d'avoir, en fait, deux objets pour accéder à une même table. Donc il n'y a pas de changement à faire dans sfGuard et tu accèdes aux données de ton user et celle de sfGuardUser par la nouvelle entité créée.


L'autre solution est plus souple et un peu plus complexe.

Tu ne touches pas à ta table sfGuardUser.

Tu modifies le modèle pour compagny de manière à ce que la création d'une compagny crée une permission dans la table sfGuardPermission et la suppression d'une compagny supprime cette permission. La permission doit être unique, le slug peut ici être une aide.

Ensuite tu attribues des droits aux users avec les processus de sfGuard sur la ou les compagnies (avec ce système, une compagnie peut aussi éventuellement avoir plusieurs user).

A l'usage, avant d'afficher une compagny, tu vérifies si l'user à les droits par un hasCredential.

Tu peux aussi auto-créer plusieurs droit comagnyname_show comagnyname_edit compagnyname_trucedit ...

Plus souple mais plus complexe

[Choucwoot]

Bonjour,

merci pour ta réponse rapide

Tu as plusieurs solutions.

Par contre ta descriptions du liens entre user et compagny n'est pas claire, tu dis : "les utilisateurs ont des company et un utilisateur loggué ne peut accéder que aux pages qui concernent sa company" ce qui laisse entendre dans la même phrase qu'un user peut avoir plusieurs compagny mais n’accéder qu'à une...

Au temps pour moi, je me suis mal exprimé, un utilisateur n'a en fait qu'une company.

Le fait de faire un héritage permet d'avoir, en fait, deux objets pour accéder à une même table. Donc il n'y a pas de changement à faire dans sfGuard et tu accèdes aux données de ton user et celle de sfGuardUser par la nouvelle entité créée.

Le soucis est que l'action signIn de sfGuardUser ne parcours que la table sfGuardUser et pas les tables filles. Ainsi si j'essaie de me logguer avec l'utilisateur user1 qui appartient à la classe User qui hérite de sfGuardUser, l'utilisateur ne sera pas reconnu tandis que si je me log avec l'utilisateur admin de la classe sfGuardUser cela fonctionne. J'ai donc essayé de créer un module sfGuardAuth pour redéfinir l'action sign in mais je ne vois pas comment je pourrai modifier cette action pour qu'elle parcour la table User.

[Michel Rotta]

Pour le coup c'est moi qui suis passé trop vite sur ton premier message.

Utilise un héritage "Column Aggregation" avec "Concrete" cela ne peut marcher.

[Choucwoot]

Très bien, j'ai donc essayé avec column aggregation ce qui me donne le schema.yml suivant (j'ai enlevé les parties superflues) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
Company:
  tableName: company
  columns:
    [...]
    idcompany:
      type: integer(4)
      primary: true
      autoincrement: true
  relations:
    User:
      local: idcompany
      foreign: idcompany
      type: many
User:
  tableName: user
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
    keyField: type
    keyValue: 1
  columns:
    idcompany:
      type: integer(4)
  relations:
    Company:
      local: idcompany
      foreign: idcompany
      type: one

Ce schema est associé aux fixtures suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
user:
  test:
    email_address: test@test.com
    username:      test
    password:      test
    Company:       companytest
 
company:
  companytest:
        [...]

La création des tables fonctionne mais au moment de charger les donner présentent dans data/fixtures j'ai l'erreur suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`test`.`sf_guard_user`, CONSTRAINT `sf_guard_user_idcompany_company_idcompany` FOREIGN KEY (`idcompany`) REFERENCES `company` (`idcompany`))

Pourtant ce type d'héritage semble accepter le fait d'ajouter une colonne aux tables filles, le problème viendrait donc de la relation avec la table company, j'ai essayé d'ajouter onDelete: CASCADE et onUpdate: CASCADE mais rien n'y fait je n'arrive pas à voir d'où peut venir le problème.
Toute proposition est la bienvenue, merci d'avance.

[Michel Rotta]

J'ai du mal avec ton schéma.

Je parie que le problème vient de la déclaration de la relation. En effet, il convient de ne déclarer une relation que d'un côté de la relation et, pour une 1-n du côté n de la relation.

De plus tu as sur Compagny une clef idcompagny en integer(4). Ce qui n'est pas "naturel" pour Doctrine.

Le mieux est de ne pas déclarer les clefs dans le shema, doctrine va créer automatiquement une clef Id en integer (soit un integer(8) )

Du coup, si j'ai bien suivi ta relation, ton schéma devient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
Company:
  tableName: company
  columns:
    [...]
  // le champs Id est généré automatiquement
 
User:
  tableName: user
  inheritance:
    extends: sfGuardUser
    type: column_aggregation
    keyField: type
    keyValue: 1
  columns:
    company_id:   // norme pour un champ de liaison
      type: integer(8)
  relations:
    Company:
      // les local er foreign sont prise par défaut vu que les noms sont
      // conform à la norme
      foreignAlias: users // "s" vu qu'une compagny peut avoir plusieurs user

Et dans ton fixature devrait passer.

Si tu veux spécifier les users d'un compagny

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
compagny:
  cmp001:
    nom: cccccc
    users: 
      usr001:
        name: xxxx
        pasword: cccc
        ...
      usr002:
        name: yyyy
        pasword: dddd
  cmp002:

ou si tu les crées en deux fois.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
compagny:
  cmp001:
    ...
    users: [ usr001, usr002 ]