Suite

Activer CORS dans GeoServer (jetée) ?

Activer CORS dans GeoServer (jetée) ?


J'espère que quelqu'un a déjà compris celui-ci. Je viens d'installer Geoserver 2.9 sur une distribution vanille Ubuntu 16.04. La méthode Geoserver 2.8 d'activation de CORS avec la classe shanbe.hezoun ne fonctionne plus avec Jetty 9.2.13.

Il est mentionné que la prise en charge de CORS est déjà fournie avec Jetty 9.2.13 dans le fichier jetty-servlets.jar.

La bibliothèque Jetty qui est compilée avec Geoserver contient un jetty-servlet-9.2.13.v20150730.jar dans geoserver/lib mais pas jetty-servlets.9.2.13.v20150730.jar. Sont-ils censés être le même pot avec un nom différent ?

Il devrait être possible d'activer CORS dans geoserver/etc/webdefault.xml ou dans geoserver/webapps/geoserver/WEB-INF/web.xml.

Ma compréhension est que le webdefault.xml est appliqué en premier et le web.xml par la suite.

J'ai essayé de suivre le filtre dans les deux xml. Je n'ai pas encore ajouté de mappage de filtre. L'ajout du filtre seul empêchera le service Geoserver/Jetty de démarrer correctement.

 origine croisée org.eclipse.jetty.servlets.CrossOriginFilter

Modifier lewebapps/geoserver/WEB-INF/web.xmlfichier. Il y a deux références à CORS dans ce fichier :

  origine croisée org.eclipse.jetty.servlets.CrossOriginFilter

et

  origine croisée /*

Toi doit décommenter tous les deux blocs (c'est-à-dire supprimerdufiltreetmappage de filtresblocs.

Ensuite, lorsque vous redémarrez Jetty, vous pouvez tester que tout fonctionne en utilisant une commande comme :

curl -v -H "Origine : http://example.com" http://astun-desktop:9080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames =sf:bugsites&filter=%3Cfes:Filter%20xmlns:fes=%22http://www.opengis.net/fes/2.0%22%3E%3Cfes:ResourceId%20rid=%22bugsites.3%22 /%3E%3C/fes:Filtre%3E

qui si tout va bien donnera un résultat comme :

> User-Agent : curl/7.35.0 > Host : astun-desktop:9080 > Accept : */* > Origin : http://example.com > < HTTP/1.1 200 OK < Access-Control-Allow-Origin : http://example.com < Access-Control-Allow-Credentials : true < Access-Control-Expose-Headers : < Content-Type : text/xml ; subtype=gml/3.2 < Content-Disposition : en ligne ; filename=geoserver-GetFeature.text < Transfer-Encoding: chunked * Server Jetty(9.2.13.v20150730) n'est pas sur liste noire < Server: Jetty(9.2.13.v20150730) < * Connection #0 to host astun-desktop laissé intact < ?xml version="1.0" encodage="UTF-8"?>590529 49146253Site de scarabée%

Mise à jour 24 octobre 2019

Il n'est plus nécessaire d'ajouter le jar suivant à GeoServer (au moins avec les versions 2.13.x et supérieures) et cela provoquera une erreur. Je laisse cette note ici pour les personnes qui combattent des versions plus anciennes.

  1. Ajoutez le Jetty-Utility Servlets Jar pour correspondre à la version de Jetty - pour les versions actuelles de GeoServer (2.15.x), il s'agit de 9.4.12.v20180830, copiez-le danswebapps/geoserver/WEB-INF/libdans le répertoire geoserver-2.15.0 (ou partout où vous avez décompressé le fichier zip).

Cela fonctionnera si vous ajoutez le filtre dans "geoserver/webapp/geoserver/WEB-INF/web.xml" et si vous ajoutez le jar "jetty-servlets.9.2.13.v20150730.jar" dans "geoserver/webapp/geoserver /WEB-INF/lib"


avec Jetty9, UbuntuServer 16.04, j'ai également dû modifier /etc/jetty9/start.ini, afin de ne pas avoir l'erreur suivante :

2018-03-31 15:10:01.769:WARN:oejuc.AbstractLifeCycle:main: FAILED cross-origin: javax.servlet.UnavailableException: org.eclipse.jetty.servlets.CrossOriginFilter javax.servlet.UnavailableException: org.eclipse.jetty .servlets.CrossOriginFilter

la solution est ici : vous devez activer le module servlets dans votre ${jetty.base}/start.ini

par conséquent, j'ai remplacé :

--module=deploy,http,jsp,jstl,websocket,ext,ressources

par :

--module=deploy,http,jsp,jstl,websocket,ext,ressources,servlets

La réponse acceptée par Ian Turton est absolument la meilleure ici. Depuis que j'utilise Docker, l'édition manuelle n'est pas le cas. De plus, je ne suis pas un gourou SED, mais grâce à la structure de web.xml (les chaînes cibles sont uniques dans la portée du document), je propose un petit extrait :

sed -i 's___' web.xml sed -i 's___' web.xml

Ou dans Dockerfile :

# activer CORS RUN wget -q http://central.maven.org/maven2/org/eclipse/jetty/jetty-servlets/9.2.13.v20150730/jetty-servlets-9.2.13.v20150730.jar -P ${ GEOSERVER_INSTALL_DIR}/WEB-INF/lib  && sed -i 's___' ${GEOSERVER_INSTALL_DIR}/WEB-INF/web.xml  && sed -i 's___' ${GEOSERVER_INSTALL_DIR}/WEB-INF/web.xml

Car tout le monde se demande quelle version de jetée vous avez pour votre application de géoserveur particulière.

Pour OSX, j'ai simplement démarré geoserver et j'ai regardé dans le journal, il devrait afficher quelque chose comme :

2019-05-10 07:25:13.444:INFO:oejs.Server:exécuteur de démarrage: jetty-9.2.13.v20150730

Je suis sûr que c'est similaire dans les journaux de Tomcat lors de l'exécution à partir d'un serveur Linux si nécessaire.

En outre, il doit être visible dans les en-têtes de réponse, c'est-à-dire :

Connexion : fermer Serveur : Jetty (9.2.13.v20150730) Options X-Frame : SAMEORIGIN

C'est-à-dire que, comme le mentionne la réponse acceptée, essayez d'utiliser la commande curl, elle présentera également la version du serveur :

curl -v -H "Origine : http://example.com" http://astun-desktop:9080/geoserver/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames =sf:bugsites&filter=%3Cfes:Filter%20xmlns:fes=%22http://www.opengis.net/fes/2.0%22%3E%3Cfes:ResourceId%20rid=%22bugsites.3%22 /%3E%3C/fes:Filtre%3E