Les services d’entités possèdent plusieurs niveaux de contrôle d’accès et fonctionnalités de suivi des mises à jour utiles pour créer des applications de mise à jour collaborative.
- Les autorisations d’éditeur déterminent si les utilisateurs peuvent ajouter, supprimer ou modifier des entités dans le service. Par exemple, vous pouvez autoriser les éditeurs à ajouter des entités mais pas à les modifier ou les supprimer.
- Le suivi de l’éditeur permet d’enregistrer l’identité des utilisateurs ayant créé ou mis à jour les entités, ainsi que la date de ces opérations. Cette fonctionnalité est utile pour savoir qui est responsable des mises à jour. Une fonctionnalité de suivi de l’historique facultative gère les informations relatives aux modifications apportées aux entités au fil du temps, ce qui permet d’annuler des mises à jour. Vous ne pouvez utiliser cette fonctionnalité qu’avec des géodatabases d’entreprise, et non avec des bases de données.
- Le contrôle d’accès basé sur la propriété vous permet de limiter l’accès aux entités en fonction de l’utilisateur qui les a créées. Par exemple, vous pouvez autoriser un utilisateur à créer et à mettre à jour ses propres données, tout en ne lui permettant que d’interroger les données créées par les autres utilisateurs. Vous ne pouvez utiliser cette fonctionnalité qu’avec des géodatabases d’entreprise, et non avec des bases de données.
Les fonctionnalités ci-dessus utilisent des jetons pour enregistrer et vérifier les noms d’utilisateur. Les développeurs peuvent obliger les utilisateurs à fournir des informations d’identification ArcGIS Server avant d’utiliser une application. Ils peuvent utiliser ces informations d’identification pour obtenir un jeton d’ArcGIS Server. Ce jeton contient des informations chiffrées sur l’identité de l’utilisateur qui se connecte et permet à un utilisateur de travailler avec les fonctionnalités du service qui correspondent à son niveau d’accès.
Vous pouvez utiliser n’importe laquelle des fonctionnalités ci-dessus, ou toutes, pour concevoir un service et ses applications. Considérons une application web permettant aux utilisateurs de signaler des délits survenus dans leur communauté. Le suivi de l’éditeur pourrait indiquer qui a signalé un délit et quand. Avec le contrôle d’accès basé sur la propriété, vous pouvez vous assurer qu’un délit signalé par une personne ne peut pas être supprimé par une autre personne (par exemple, l’auteur du délit). Enfin, vous pourriez désactiver la fonctionnalité de modification de délits existants et n’autoriser que les ajouts et les suppressions.
Scénarios d’autorisations de services d’entités et de suivi de l’éditeur
Voici quelques autres scénarios dans lesquels une combinaison de fonctionnalités d’autorisations d’éditeur, de suivi de l’éditeur et de contrôle d’accès basé sur la propriété serait utile dans une application. Ces scénarios vous aideront à comprendre comment définir la meilleure combinaison de propriétés dans votre service d’entités, en fonction de l’objectif de votre application.
Bénévole uniquement
Dans une application web de type bénévole uniquement, tous les éditeurs sont des bénévoles anonymes. Une application web permettant à l’utilisateur de placer un point sur son emplacement actuel pourrait correspondre à cette description. Dans ce scénario, le service ne pourrait exposer que des opérations de requête et de création. Parce que les entités ne seront pas modifiées, effectuer le suivi des auteurs des données n’est pas une priorité. Le suivi de l’éditeur et l’historique ne sont pas non plus nécessaires. L’administrateur pourrait ouvrir le jeu de données dans ArcGIS Pro si nécessaire et supprimer les entités indésirables.
Officiel uniquement
Dans une application de type officiel uniquement, tous les utilisateurs peuvent mettre à jour les données, mais les mises à jour font l’objet d’un suivi. Par exemple, ce type d’application pourrait permettre à des personnes de collaborer sur un inventaire d’arbres numérique dans leur ville. Les bénévoles pourraient ajouter, modifier ou supprimer un arbre de la base de données, mais il leur faudrait se connecter à l’application pour apporter des mises à jour.
Dans une application de type officiel uniquement, les utilisateurs peuvent interroger l’historique d’une entité pour savoir qui a modifié cette entité et quand. Si nécessaire, un administrateur peut annuler une mise à jour. Le dernier éditeur de chaque entité fait l’objet d’un suivi et est stocké dans la base de données.
Bénévole et officiel
Vous pouvez utiliser plusieurs services d’entités dans une application nécessitant à la fois une approche de type officiel et une approche de type bénévole. Par exemple, supposons que vous travaillez au sein d’une équipe de biologistes collectant des informations sur la faune d’un parc national. Chaque membre de l’équipe est responsable d’un domaine d’étude, mais vous souhaitez collaborer afin de pouvoir effectuer des analyses et publier vos conclusions concernant le parc entier. Vous souhaitez également collecter des images et des vidéos, ainsi que les commentaires des visiteurs du parc.
Pour gérer la collecte de ces éléments, vous pourriez exposer un service d’entités d’habitat, que seuls les biologistes pourraient modifier, et un service d’entités ponctuelles d’observation, que tout le monde pourrait modifier. Le développeur de l’application web pourrait écrire une logique permettant aux biologistes qui se connectent de voir les deux services d’entités, tandis que les utilisateurs anonymes ne verraient que le service d’entités ponctuelles d’observation et, éventuellement, une image non modifiable des zones d’habitat affichée par le service de carte.
Vous avez un commentaire à formuler concernant cette rubrique ?