Open fsteggink opened 3 years ago
It looks like you hit the Test button before saving? You first need to do Save and then Test. Otherwise the form is not saved. This may not be obvious from a UI perspective, improvement welcomed. Let's first see if that (not clicking Save first) was the reason.
I've just noticed that the first probe by ghc_runner fails as well. Perhaps this has the same cause. Too early to tell. I'll create a new issue if this has a different cause.
It looks like you hit the Test button before saving? You first need to do Save and then Test. Otherwise the form is not saved. This may not be obvious from a UI perspective, improvement welcomed. Let's first see if that (not clicking Save first) was the reason.
Save + Test results in the test being succeeded. :+1:
But the first probe run still fails (as reported only 2 mins ago)
Yes, this is a bit tricky: when adding a new Resource, we want users to specify an absolute minimum, only the endpoint URL. GHC then assigns and runs the default Probe for the endpoint type, usually a GetCapabilities
Probe.
This can even be overridden (GHC_PROBE_DEFAULTS
), maybe you can make this empty (?), so that assignment/run is skipped (?).
In earlier versions the Resource was not added if that default Probe failed. But now it is added unconditionally. I can see that this is an issue for authenticated Resources. A solution would be to add auth-fields to the 'Add Resource' form.
When I'm adding a new WMS resource, specify "Basic Authentication" username + password, and then press the "Test" button at the Action row at the bottom of the page, I'm getting a result indicating that the test has failed. Details:
I was expecting a successful test result. When I save and close the resource, reopen it and then press "Test now", then the test passes successfully. Also when I press "Edit" and then the same "Test" button as in the beginning, the test succeeds. It is as if the credentials aren't used when the new check isn't saved to the database yet.
Also note that the resource title is "Untitled", although I had already given the new resource a proper name before I performed the test.
Output of
docker logs ghc_web
:Note the line with
https://<my server>:443 "GET /login.html?httpd_location=<path>?service=WMS&request=GetCapabilities&version=1.3.0 HTTP/1.1
. I've set up my web server in such a way that when no authorization headers are provided the user is redirected to a login page. Obviously this is not a valid GetCapabilities document, hence the various kinds of errors (invalid XML and missing Title string).