Explications des droits du RS

Nous avons une user pool qui nous permet de gérer la pool des users afin que la personne ai 1 compte pour les différents applications qu'il aura.

Je ne suis plus certain de la réel plus value de faire une user pool car de toute manière le profil dans rs est lié à plusieurs organization, et le jour ou on fera plusieurs application, on aura les droits défini dans la table de pivot entre profiles et organizations.

Si l'on passe sur cette méthode et qu'on enlève la user pool, plus besoin d'avoir un user token

Droits

Dans le dossier rs-perms dans /deploy/resources, vous trouverez tous les droits spécifiés par route.

Les différents droits sont les suivants:

• admin: // est devenu obsolète, les routes du bo sont maintenant gérées par un autre authorizer
• user: défini le user lambda qui a certains droits (ex: les managers, les externes, les visiteurs, les providers)
• quoteUser: // est pour l'instant obsolète
• provider: défini si la route est accessible par un provider
• visitor: défini si la route est accessible par un visiteur

Donc il faut mettre toutes les routes lambda dans user. Mais l'on a une deuxième vérification avec le middleware checkPermissions.

// faire que les droits dans la user pool match ceux dans la table de pivot de permission ? // pas possible car on a des droits par organisation.

// soit le champ "admin" dans la table est obsolète, et on est obligé de mettre tout dans user. // probablement car "admin" était pour les routes actuellement du backoffice. // le admin ne défini pas

Middleware checkPermissions

Ce middleware permet de faire une deuxieme vérification des droits utilisateurs. Il permet de bien si l'utilisateur est admin, ou bien juste utilisateur.

Sign out

Cette route fait un sign out des tokens. Sauf que elle prend effet seulement au moment du refresh token qui fait la vérification.