Français
  • A propos du composant BSPK
  • ATL
  • BWEB
  • Historique des versions
  • FAQ

    • Utilisateurs et droits

    Cinq tables portent les utilisateurs, les groupes et les droits :

    TableContenu
    BSPK_USERLes utilisateurs web
    BSPK_USER_GROUPLes groupes
    BSPK_USER_MEMBERSHIPQui appartient à quel groupe
    BSPK_USER_RIGHTLes droits eux-mêmes
    BSPK_USER_RIGHT_RULELa façon dont un droit est accordé

    Un droit est référencé depuis une page (userRightUuid, editRightUuid) et depuis un bloc (userRightNeeded).

    WebUser est une entité

    Ce n'est ni un objet, ni un sac de session : c'est une entité. Traitez-la comme telle. Elle a des attributs, et demander une propriété qui n'existe pas renvoie undefined au lieu de lever une erreur.

    Les écrans d'administration utilisent un droit, pas un code écrit en dur

    L'accès à /bweb/* passe par un droit ADMIN_<SLUG>. L'ancien code testait code = "DEV" ; ce n'est plus le modèle.

    Deux échecs possibles, trompeurs tous les deux :

    • une 404 causée par un publish nul sur une URL d'administration : elle ressemble à une route manquante, c'est une page non publiée ;
    • une 403 sur tous les événements d'un écran d'administration tant que le droit n'est pas accordé : elle ressemble à un bouton cassé.

    Les droits d'affichage ne sont pas un contrôle d'accès

    userRightNeeded décide si un bloc est rendu. À lui seul, il ne protège pas les données : hidden envoie quand même le contenu au navigateur. Pour tout ce qui ne doit pas atteindre un visiteur non autorisé, utilisez notLoaded ou un droit au niveau de la page. Et rappelez-vous que le POST est revérifié quoi qu'il ait été affiché (voir La sécurité).

    Un utilisateur dont le code est rempli peut disparaître des listes

    Un vt_FirstRequest écrit code = '' écarte tous les utilisateurs qui ont un code, en silence et partout à la fois : liste, filtres, export, fusion. Si des utilisateurs manquent sur tous les écrans, regardez la première requête avant de regarder les droits.

    Les sessions

    La session de connexion est perdue au redémarrage de 4D : c'est pourquoi le dev-panel disparaît et qu'il faut repasser par /bweb/login. Un cookie de persistance n'est recréé que lorsqu'un utilisateur est réellement connecté ; sans cela, une déconnexion ne tiendrait jamais.

    Voir aussi