Open bchartier opened 5 years ago
Je trouve que c'est une bonne idée. Comment récupérer l'information de l'accès restreint ? Dans la métadonnée ?
Je ne propose pas qu'on le détecte automatiquement que je le créateur de la carte coche une case s'il sait qu'elle est en accès restreint.
Sinon, à terme, on pourrait rechercher un moyen de le détecter automatiquement mais le souci c'est que ce n'est pas une information retournée par le service.
Rechercher dans les métadonnées pourrait être une piste mais le résultat sera moyen. On pourrait envoyer des requêtes de test pour voir si le serveur demande une authentification mais cela risque d'être un énorme bricolage et dépendre beaucoup des serveurs interrogés.
Dans un premier temps, je propose la solution de cocher une case dans studio quand on déclare la couche.
ça me va.
Je me rends compte qu'il y a quelque chose qui ressemble dans le code de mviewer et mviewerstudio : le paramètre layer.secure. Dans mviewer je ne comprends pas bien ce qui est fait : https://github.com/geobretagne/mviewer/blob/cb92ad5ad9ce64edf55dd6903a761f41cc4f0515/js/configuration.js#L300-L318
Si la couche est marquée comme "secure" alors on teste sa présence dans les capabilities et si la couche n'y est pas présente alors on la supprime de la liste des couches de la carte, c'est ça ?
D'ailleurs, après avoir fait un test sur une couche en acccès retreint j'obtiens une exception sur le code gérant la suppression de la couche :
Uncaught TypeError: Cannot read property 'layer' of undefined at Object._deleteLayer [as deleteLayer] (mviewer.js:315) at Object.success (configuration.js:314) at c (jquery-1.10.2.min.js:4) at Object.fireWith [as resolveWith] (jquery-1.10.2.min.js:4) at k (jquery-1.10.2.min.js:6) at XMLHttpRequest.r (jquery-1.10.2.min.js:6)
L'exception n'a pas l'air de se produire systématiquement.
Pour revenir à la manière de gérer les couches en accès restreint je vois 2 possibilités pour améliorer l'usage du paramètre secure :
On pourrait imaginer modifier ce comportement pour avoir 3 modes au lieu des 2 actuels :
On pourrait également ne pas aller aussi loin et simplement modifier légèrement le comportement actuel lorsque la couche est supprimée : afficher une pop-up pour avertir l'utilisateur qu'une couche en accès restreint n'a pas pu être chargée.
Je me rends compte qu'il y a quelque chose qui ressemble dans le code de mviewer et mviewerstudio : le paramètre layer.secure. Dans mviewer je ne comprends pas bien ce qui est fait : https://github.com/geobretagne/mviewer/blob/cb92ad5ad9ce64edf55dd6903a761f41cc4f0515/js/configuration.js#L300-L318
Si la couche est marquée comme "secure" alors on teste sa présence dans les capabilities et si la couche n'y est pas présente alors on la supprime de la liste des couches de la carte, c'est ça ?
Cest tout à fait ça
A la région, nous utilisons souvent de paramétrage de couche en accès restreint. Et nos utilisateurs y tiennent beaucoup. Par contre, la vérification actuelle de l'accessibilité de la couche via les capacités consomme beaucoup de ressources et n'est pas optimisée. En effet si une application contient 10 couches sécurisées, 10 GetCapabilities sont effectués à la suite même si les couches sont disponibles dans le même service WMS.
On pourrait imaginer modifier ce comportement pour avoir 3 modes au lieu des 2 actuels :
- mode normal : on ne fait aucun contrôle et on affiche la couche dans la liste des couches de la carte
- mode secure actuel
- mode secure + cadenas : la couche est conservée dans la liste quoi qu'il arrive mais on lui associe un picto de cadenas pour indiquer qu'elle est protégée.
Ok avec la proposition. La couche serait donc visible dans le panneau des thématiques mais "désactivée" et marquée par un cadenas, c'est bien ça ?
On pourrait imaginer modifier ce comportement pour avoir 3 modes au lieu des 2 actuels :
- mode normal : on ne fait aucun contrôle et on affiche la couche dans la liste des couches de la carte
- mode secure actuel
- mode secure + cadenas : la couche est conservée dans la liste quoi qu'il arrive mais on lui associe un picto de cadenas pour indiquer qu'elle est protégée.
Ok avec la proposition. La couche serait donc visible dans le panneau des thématiques mais "désactivée" et marquée par un cadenas, c'est bien ça ?
Je précise pour être sûr qu'on soit d'accord: Si on tague la couche avec ce 3e mode :
Est-ce qu'on garde le mode actuel ? Si on le garde il faudra prévoir de remplacer la case à cocher par une liste déroulante ou des boutons radio.
A la région, nous utilisons souvent de paramétrage de couche en accès restreint. Et nos utilisateurs y tiennent beaucoup. Par contre, la vérification actuelle de l'accessibilité de la couche via les capacités consomme beaucoup de ressources et n'est pas optimisée. En effet si une application contient 10 couches sécurisées, 10 GetCapabilities sont effectués à la suite même si les couches sont disponibles dans le même service WMS.
Oui, on pourrait récupérer les capabilities de tous les services au préalable du test ce qui permettrait de ne faire qu'un seul GetCapabilities si jamais c'est le même service pour toutes les couches en accès restreint.
Est-ce qu'on garde le mode actuel ? Si on le garde il faudra prévoir de remplacer la case à cocher par une liste déroulante ou des boutons radio.
Je me dis que l'on peut ne conserver qu'un seul mode (la propriété "secure" actuelle) et avoir une option au niveau de la carte pour déterminer le comportement global :
Cela me semblerait plus pertinent comme cela. En plus cela m'éviterait de toucher le formulaire de la couche.
Ta dernière proposition me convient.
Parfait.
@spelhate : j'ai l'impression que c'est fait. On ferme ?
Lors d'une discussion avec le CRIGE PACA a émergé l'idée de pouvoir mettre en évidence que certaines couches de la carte puisse être en accès restreint. L'idée serait qu'on puisse dans le studio marquer une couche comme faisant l'objet d'une restriction d'accès et que cela apparaisse visuellement quelque part mviewer ensuite (une icône de cadenas par exemple).
Personnellement cela me plaît bien comme idée. Une réaction ?