Select to view content in your preferred language

WMS service popups not working

6229
3
Jump to solution
11-17-2018 10:51 AM
Jeremy_Moore
MVP Alum

WMS service popups not working in Map viewer or Web Mapping Application. The WMS service is hosted by geoserver and I can get the popup's to work VIA WFS service however WFS is not preferable. I'm not sure what is going on with the popup windows however when I inspect the popup window to take a look at the GetFeatureInfo request it works fine in a web browser but show up in AGOL as a sad face and a message saying my server did not respond. Here are two pictures. One of the error and the inspection of the GetFeatureInfo request.  The second image is of the exact same GetFeatureInfo request from the AGOL Map Viewer popup opened in a web browser.

My WMS service adhears to the TEXT/PLAIN or TEXT/HTML output needed to work in AGOL.

You can test the WMS service VIA: http://216.250.126.203:8080/geoserver/wms_test/wms

Hopefully someone can lend me a hand if I'm doing something wrong.

There is also what looks to be a java error being kicked out by chrome for the popup iframe to display the WMS GetFeatureInfo. I have a feeling this might be a bug with Web Map Viewer.

Refused to display 'http://216.250.126.203:8080/geoserver/wms_test/ows?SERVICE=WMS&REQUEST=GetFeatureInfo&FORMAT=image/p...' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

AGOL Web Map Viewer Iframe GetFeatureInfo request

Web browser output of the GetFeatureInfo request

1 Solution

Accepted Solutions
Jeremy_Moore
MVP Alum

After Spending some time trouble shooting and going through all of my browsers and GeoServer files to make sure everything was up-to-date I finally had a break through. When opening the Map that contains the WMS service in Internet Explorer, the error in the popup window was much more descriot. As it turns out, GeoServer stops webpages from using X-Frames to display the GetFeatureInfo requests. There are several ways to fix this, you can change the web.xml file for GeoServer to allow X-Frames. Or if you are running the server on a Windows OS you can change the X-Frames properties via the start script for the server (startup.bat).

To change the properties from the web.xml file, GeoServer has a web page with the necessary properties that you will have to change. However this doesn't work for some people. 

Configuration Considerations — GeoServerUser Manual 

If you are running a Windows OS you can change the startup.bat file which is located in the GeoServers bin folder (data/bin/)

You then add one of the lines of code below to the very top:

set geoserver.xframe.shouldSetPolicy=false        

set geoserver.xframe.policy=ALLOW-FROM http://yourgeoserveraddress.com

The first line of code will allow all connections to use the X-Frame. The second line of code acts as a while list which will allow only your GeoServer. So the web address can be set to your GeoServers IP address or it can be set to 127.0.0.1:8080   So it would look something like this:

set geoserver.xframe.policy=ALLOW-FROM http://127.0.0.1:8080

If for some odd reason that is not working try 127.0.0.1:8080/geoserver

Once the changes have been made restart geoserver and enjoy.

View solution in original post

3 Replies
Jeremy_Moore
MVP Alum

After Spending some time trouble shooting and going through all of my browsers and GeoServer files to make sure everything was up-to-date I finally had a break through. When opening the Map that contains the WMS service in Internet Explorer, the error in the popup window was much more descriot. As it turns out, GeoServer stops webpages from using X-Frames to display the GetFeatureInfo requests. There are several ways to fix this, you can change the web.xml file for GeoServer to allow X-Frames. Or if you are running the server on a Windows OS you can change the X-Frames properties via the start script for the server (startup.bat).

To change the properties from the web.xml file, GeoServer has a web page with the necessary properties that you will have to change. However this doesn't work for some people. 

Configuration Considerations — GeoServerUser Manual 

If you are running a Windows OS you can change the startup.bat file which is located in the GeoServers bin folder (data/bin/)

You then add one of the lines of code below to the very top:

set geoserver.xframe.shouldSetPolicy=false        

set geoserver.xframe.policy=ALLOW-FROM http://yourgeoserveraddress.com

The first line of code will allow all connections to use the X-Frame. The second line of code acts as a while list which will allow only your GeoServer. So the web address can be set to your GeoServers IP address or it can be set to 127.0.0.1:8080   So it would look something like this:

set geoserver.xframe.policy=ALLOW-FROM http://127.0.0.1:8080

If for some odd reason that is not working try 127.0.0.1:8080/geoserver

Once the changes have been made restart geoserver and enjoy.

MichelleDouville
New Contributor

We had the same issue, our geoserver is behind a reverse proxy. But something on ESRI's AGO stack changed recently to make the default Apache web server behaviour no longer acceptable to AGO. The default behaviour is to return SAMEORIGIN as a header response (if it isn't defined in the apache or other web proxy configs) -

X-Frame-Options: sameorigin

see -  X-Frame-Options | MDN 

For AGO to work with our web services we needed to update our web proxy service to explicitly include a declaration like this in the header response:

X-Frame-Options: allow-from 'uri'

NOTE: this isn't something specific to Geoserver.

0 Kudos
PiotrBordzań
Emerging Contributor

Hello, 

I want to add a small sipicy news for this topic.

It is not full solutions for this discuss. Because, I have the same issue about SAMEORGIN. It's default parameter for securing Geoserver by "clickjacking" attack Geoserver doc 

In this same time It's not problem to display popup into ArgisPro and QSIS desktop apps. So anyone know, how it's works?

And last think, I added this same URL into local publishing WebMap portal and popUp respond correctly, screenshot into attach.


In conclusion, the problem is not the geoserver but rather the parameter in AGOL

 

0 Kudos