Hi all,
I’m writing to the dev list as I’m facing extended troubles with the CSP headers being on by default, and I’m not getting any traction trying to discuss the issues on the PR that triggered them.
Long story short, there is a number of problems in the GeoServer GUI, several parts of which are not working any longer to due CSP blocking some of the page functionality.
Many of the problems seem to originate in some sort of HTTP caching of the pages, where the CSP headers are enabled anyways (OPTIONS/preflight requests maybe?) but the content of the page is outdated. Not sure why it’s happening, but I see it a lot: I can regain full functionality of some pages by force reloading them (CTRL-F5), while others just do not work.
One example is the layer preview page, the format dropdowns would not work and open a preview with the selected format (with a CSP error) until I force reload the page.
One more thing I’ve noticed is that the issues are not the same when running locally, or running in a published web site, with more issues when running in a published website (typically fronted by nginx or apache), even if the caching headers are still set to “not cache” (max-age=0 and the like).
First of all, can anyone else reproduce these issues?
If so, we shoudl think of something… even if CSP is not entirely at fault here, plenty of people upgrading will just assume the GUI broke, and even for those that do read the upgrade instructions, we cannot really ask them to force reload every page.
Yes, I am having the same problems on 2.27.x (main) deployed for CITE testing.
Refused to send form data to ‘https://___________/geoserver/j_spring_security_check’ because it violates the following Content Security Policy directive: “form-action ‘self’”.
Refused to load the stylesheet ‘https://___________/geoserver/web/wicket/resource/org.wicketstuff.select2.ApplicationSettings/res/css/select2-ver-E6DE4A7C42DF8ED98269C8B60F7C4DCD.css’ because it violates the following Content Security Policy directive: “style-src ‘nonce-lUa1lE_1TRo674n0kKTLQEFi’”. Note that ‘style-src-elem’ was not explicitly set, so ‘style-src’ is used as a fallback.
I don’t know if it’s a proxy configuration issue, a GeoServer configuration issue or a bug in the GeoServer code but the form-action 'self' CSP violations are actually because the server is redirecting the HTTPS request to HTTP so they are considered to be different origins (https://gs-main.geosolutionsgroup.com to http://gs-main.geosolutionsgroup.com). The HTTP URL returns a 404 Not Found error so this redirection can cause requests to fail even when it isn’t blocked by CSP.
I think I’m finding CSP issues - I saw some CSP errors in the browser. I turned them off with org.geoserver.web.csp.strict=false and now there’s no errors in my js console.
However, when I access the WCS request builder, and click on an EPSG code (to pop up a dialog), nothing happens. Looking into it…
Tomcat: The scheme (=protocol) Tomcat shall assume on inbound requests is directly configurable, regardless of the real protocol in use. See scheme in Apache Tomcat 9 Configuration Reference (9.0.98) - The HTTP Connector
Of course this breaks accessing Tomcat directly using HTTP.