Les services d'entités présentent plusieurs niveaux de contrôle d'accès et des fonctions de suivi des mises à jour utiles lorsque vous créez des applications d'édition collaboratives.
- Les autorisations de l'éditeur déterminent si les utilisateurs peuvent ajouter, supprimer ou modifier des entités du service. Vous pouvez, par exemple, permettre à des éditeurs d'ajouter des entités, sans pour autant pouvoir les modifier ni les supprimer.
- Le suivi d'éditeur permet d'enregistrer l'identité des utilisateurs ayant créé ou mis à jour les entités, ainsi que la date de ces modifications. Cela est utile lorsque la personne responsable des mises à jour doit être identifiée. Une fonction facultative de suivi de l'historique permet de conserver les informations liées aux modifications apportées aux entités, ce qui permet d'annuler les mises à jour. Vous pouvez uniquement utiliser ces fonctionnalités 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 à des entités en fonction de leur créateur. Par exemple, vous pouvez autoriser des utilisateurs à créer et mettre à jour leurs propres données tout en les limitant à interroger uniquement celles créées par d'autres utilisateurs. Vous pouvez uniquement utiliser ces fonctionnalités avec des géodatabases d'entreprise, et non avec des bases de données.
Les entités ci-dessus utilisent des jetons pour enregister et vérifier des noms d'utilisateurs. Les développeurs peuvent forcer des utilisateurs à fournir des informations d'identification pour se connecter à ArcGIS Server avant d'utiliser une application. Les développeurs utilisent alors ces informations d'identification pour obtenir un jeton auprès d'ArcGIS Server. Le jeton contient des informations chiffrées sur l'identité des utilisateurs qui se connectent et il permet à un utilisateur d'utiliser des entités du service en fonction du niveau d'accès qui leur a été accordé.
Vous pouvez utiliser toutes les fonctions susmentionnées, ou uniquement certaines, lorsque vous créez un service et les applications qui l'accompagnent. Vous pouvez créer une application Web qui permet aux utilisateurs de signaler des actes criminels dans leur communauté. Le suivi de l'éditeur peut également vous indiquer qui a signalé un acte criminel et à quel moment. En bénéficiant d'un accès basé sur la propriété, vous pouvez vous assurer qu'un acte criminel signalé par un citoyen ne peut pas être supprimé par un autre cityoen (la personne à l'origine de cet acte, par exemple). Vous pouvez également désactiver la fonction qui permet de modifier les actes criminels, et n'autoriser que les ajouts et les suppressions.
Scénarios illustrant les autorisations de services d'entités et de suivi de l'éditeur
Voici d'autres scénarios qui illustrent l'utilité d'une combinaison d'autorisations de l'éditeur, de suivi de l'éditeur et de contrôle d'accès basé sur la propriété. Ces scénarios vous aideront à comprendre comment définir les combinaisons de propriétés les mieux adaptées sur votre service d'entités, selon la fonction de votre application.
Volontaire uniquement
Dans un type d'application Web Volontaire uniquement, tous les éditeurs sont des volontaires anonymes. Une application Web permettant à des personnes de placer un point là où ils se trouvent correspond à cette description. Dans ce scénario, le service ne doit proposer que les opérations Interroger et Créer. Puisque les entités ne seront pas modifiées, le suivi des créateurs des données n'est pas essentiel. Les fonctions de suivi de l'éditeur et d'historique ne sont pas non plus requises. L'administrateur peut ouvrir le jeu de données dans ArcGIS for Desktop si cela est nécessaire et supprimer les entités indésirables.
Autorité uniquement
Dans un type d'application Autorité uniquement, tous les utilisateurs peuvent mettre à jour les données, mais les mises à jour sont suivies. Par exemple, ce type d'application permet aux utilisateurs de collaborer sur un inventaire numérique des arbres dans leur ville. Les volontaires peuvent ajouter, modifier ou supprimer un arbre de la base de données, mais ils doivent se connecter à l'application pour effectuer des mises à jour.
Dans une application de type Autorité uniquement, les utilisateurs peuvent interroger l'historique d'une entité pour savoir qui l'a modifiée et à quel moment. Si cela est nécessiare, un administrateur peut annuler une mise à jour. L'éditeur le plus récent de chaque entité est suivi et stocké dans la base de données.
Volontaire et autorité
Vous pouvez utiliser plusieurs services d'entités dans une application dans laquelle les approches Volontaire et Autorité doivent être utilisées. Par exemple, supposez que vous travaillez avec une équipe de biologistes qui rassemble des informations sur l'habitat naturel dans un parc national. Chacun de vous est responsable d'une zone d'étude, mais vous souhaitez collaborer pour effectuer des analyses et publier des informations sur le parc entier. Vous souhaitez également rassembler des images, des vidéos et des commentaires des visiteurs du parc.
Pour gérer ces informations, vous pouvez créer un service d'entités d'habitat naturel que seuls les biologistes peuvent mettre à jour et un service d'entités de points d'observation que tous les utilisateurs peuvent mettre à jour. Le développeur de l'application Web peut rédiger une logique stipulant que les biologistes qui sont connectés peuvent voir les deux services d'entités, alors que les utilisateurs anonymes ne peuvent voir que le service d'entités de points d'observation et éventuellement une image non modifiable des zones d'habitat naturel, dessinée par le service de carte.
Vous avez un commentaire à formuler concernant cette rubrique ?