Cette étiquette réunit tous les publications liées aux rôles (conteneur qui détient un ou plusieurs privilèges pour l'accès aux tables SQL), aux utilisateurs (identité du login lorsqu'il est connecté à une base de données) et à l'autorisation (fonction de spécification des droits d'accès/privilèges aux ressources). Pour en savoir plus sur les rôles, les utilisateurs et l'autorisation, consultez la rubrique Documentation.
Introduction
"Cela fait trente secondes que j'attends un service. C'est scandaleux ! Je m'en vais !"
"Je suis désolé d'entendre cela, monsieur. La prochaine fois, vous devriez peut-être réserver."
Si vous entendiez ce commentaire dans votre restaurant préféré, vous penseriez que la personne qui le fait est ridicule. Cependant, dans le contexte de votre API, ce commentaire est parfaitement logique. Tout comme votre restaurant préféré, votre API a des clients réguliers qui, comme vous le savez, viendront un jour ou l'autre. Il serait formidable de pouvoir faire une réservation permanente pour eux aussi.
Jusqu'à présent, nous avons expliqué comment utiliser ObjectScript pour gérer les utilisateurs, les rôles, les ressources et les applications. Il existe quelques autres classes dans ce package qui fonctionnent de manière similaire à celles mentionnées ci-dessus. Cependant, ces quatre classes sont celles que chacun devra utiliser pour gérer la sécurité de ses applications. Supposons que vous souhaitiez créer votre propre portail de gestion de la sécurité pour ce package. Il y aurait des problèmes spécifiques à prendre en compte pour une API. Étant donné que les classes utilisent des méthodes
Bonjour la communauté,
je vous invite à regarder la nouvelle vidéo sur InterSystems Developers YouTube:
Lors de la création d’un PRA (Privileged Routine Application; qui d’ailleurs n’est pas pertinent uniquement pour les routines mais aussi pour les classes/méthodes), il est important de s’assurer d’inclure un new $ROLES, avant d’appeler AddRoles(). Par exemple:
New $ROLES
set status=$System. Security.AddRoles(« MyPrivilegedRoutineApplication »)
De cette façon, vous vous assurez que les rôles ajoutés (élevés) « s’évaporent » pour l’utilisateur exécutant ce code, une fois que l’utilisateur est hors du champ d’application de cette routine / méthode.
[Merci @Andreas Dieckow d’avoir validé cela]