We had a cascaded WMS working in 2.28.5. After upgrade to 3.0.1, it is failing to load in a WMS client (QGIS). The remote WMS loads fine in QGIS direct without Geoserver cascading it. It appears to be timing out after a long delay in QGIS. Log includes:
Thanks to Jody (again), confirmed that the issue is with schema access restrictions: setting ENTITY_RESOLUTION_UNRESTRICTED=true brings the layer to life, but is not suitable for production. I’ll see if I can find which calls are not being matched by my URL check.
The positive result with ENTITY_RESOLUTION_UNRESTRICTED=true might have been a false positive. I appear to be experiencing the issue intermittently. I have a few follow-up questions, if anyone can help me (I appreciate some of these are not pure Geoserver questions):
In the Geoserver admin interface (Security > URL Checks), does checking or unchecking “URL checks are enabled” take immediate effect? There is no save button.
I am trying to write a regex to allow the remote WMS in URL Checks. When I test a URL against it in Geoserver admin (Security > URL Checks > Test URL Checks with external URL), it does not match. When I try to use regex101.com, it matches (I’ve tried PCRE, Java, and Javascript options, and tried removing both /g and /m flags which it enables by default). How do I find out where the error lies?
Is there a method (Tomcat/Ubuntu) to add ENTITY_RESOLUTION_UNRESTRICTED=true without restarting the Tomcat service? I’ve tried adding it to /etc/environment, but since my attempts are proving inconclusive, it’s hard to know whether Geoserver observes that immediately.
Huh - It sounds like you may have an actual time out on the WMS service being accessed?
You could try using control-flow to avoid hitting the service concurrently if it is struggling to keep up with your requests (or limiting the number of requests you can make).
For your questions:
The URL checks should have a save button?
There are some examples in docs? You should be able to adapt for a WMS service:
There is no way to configure ENTITY_RESOLUTION_UNRESTRICTED without restarting tomcat, the point of such settings is to place them out side of administrator control.
Especially for ENTITY_RESOLUTION_UNRESTRICTED=true setting is not to be used in production; but it was successful then you confirms that schema resolution was part of the problem to be fixed using entity resolution allowlist: ENTITY_RESOLUTION_ALLOWLIST=server1|server2
Some information from the remote WMS provider: they do not support GetLegendGraphic. This is confirmed in the GetLegendGraphic response from GeoServer:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE ServiceExceptionReport SYSTEM "https://xxx.xxx.com/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd">
<ServiceExceptionReport version="1.1.1" >
<ServiceException>
Can't obtain the schema for the required layer.
Server does not specify a GetLegendGraphic operation. Cannot be performed
</ServiceException>
</ServiceExceptionReport>
Requesting the remote WMS directly in QGIS results in only GetCapabilities and GetMap calls, no GetLegendGraphic. The remote WMS’s response to GetCapabilities contains no GetLegendGraphic entity. Calls to the cascaded GeoServer layer, however, include GetLegendGraphic:
Each layer also includes a GetLegendGraphic URL in Style.LegendURL.OnlineResource.
As a test, I also tried to configure the GeoServer WMS in QGIS with the option “Ignore GetMap/GetTile/GetLegendGraphic URI reported in GetCapabilities”. This seemed to make no difference.
Is it possible when configuring either the WMS cascade store in GeoServer, or the layer itself, to prevent GetLegendGraphic requests or to handle their response better in this situation?
Just to be clear, this layer worked in GeoServer 2.28.5, and failed on upgrade to 3.0.1.