Après 2015-juil-14
La situation s'est beaucoup améliorée. L'administrateur de l'organisation peut créer un groupe dont les membres peuvent mettre à jour l' autorisation des éléments . Cela supprime le besoin d'informations d'identification de connexion partagées et / ou donne à tous les éditeurs des privilèges d'administrateur à l'échelle de l'organisation * , tout en rendant les autorisations de groupe réponse ** viables pour les cartes publiques.
La nouvelle pratique recommandée est la suivante:
- Désactiver la modification entièrement sur le service de fonctionnalités hébergé
- En tant qu'administrateur de l'organisation: créez un groupe de rédacteurs et accordez la nouvelle autorisation «Les membres peuvent mettre à jour», remplissez si nécessaire. (Doit être un nouveau groupe, créé après juillet 2015).
- Dans une utilisation quotidienne, les éditeurs utilisent «Ajouter une couche à la carte avec l'édition activée» à partir de la page des détails de l'élément pour remplacer l'indicateur de lecture seule.
Pour plus de détails, voir Voir Permettre à des collègues de mettre à jour vos cartes et applications dans le blog ArcGIS et Meilleures pratiques pour l'utilisation de couches dans les cartes dans l'aide en ligne.
...
Je nourris certaines réserves car le modèle de sécurité sous-jacent † ne semble pas avoir changé, le service de fonctionnalités lui-même n'a pas de concept d'utilisateur ou de groupe autorisé. Je pense qu'il y a encore de la place pour des problèmes, mais au moins la surface est considérablement réduite et la possibilité de dommages accidentels et simplement causés par les données est supprimée.
Veuillez également noter que les services existants utilisant les anciennes méthodes sont toujours vulnérables. Hier, lors de mes tests, j'ai découvert facilement des services d'entités exposés involontairement en recherchant simplement sur arcgis.com "Modifier la couche de services d'entités".
Avant 2015 juillet
Nous avons eu une longue conversation avec des gens d'Esri Canada à ce sujet en février 2015. Il n'y a pas de méthode sécurisée pour régir les rôles de privilèges de modification et de lecture seule simultanés dans ArcGIS Online (actuellement). Le mieux que l'on puisse faire est d'obscurcir l'emplacement du service modifiable, selon les réponses de Brad et Bmearns ici, puis d'activer l' éditeur de pistes . Cela serait suivi d'examens périodiques des enregistrements et de suppression de ceux qui n'ont pas été effectués par une personne autorisée à le faire.
Une mesure de protection supplémentaire (petite, faible) peut être d'ajouter un filtre à la carte Web pour afficher uniquement les enregistrements où Creator is not {one space}( n'est pas vide ne fonctionne pas). Cela n'affecte que cette carte Web. Les personnes contournant la carte Web et accédant directement au service d'entités voient tout.
Si un service d'entités sécurisé et modifiable est nécessaire, vous devez exécuter votre propre ArcGIS Server ailleurs avec le partage et la modification verrouillés au besoin, puis un service en lecture seule exposé à ArcGIS Online.
Cela permet d'utiliser la disponibilité massive, la mise en cache du réseau de distribution de contenu, la mise à l'échelle du processeur / de la mémoire, etc. de l'infrastructure ArcGIS Online pour une consommation publique en lecture seule généralisée avec un accès en modification sur une machine plus répartie et moins coûteuse. Vous n'allez pas réunir les deux au même endroit, avec ArcGIS Online.
mise à jour , 2015-May-27: ajout du filtre par astuce du créateur
