Hi all,
I’m looking at an issue that’s leaving me… surprised.
Say you are a workspace administrator, with limited configuration abilities.
One of the things that can be modified is the workspace itself, in terms of enabling/disabling workspace local services:
However when trying to edit the WFS service (for example) then the following happens:
This seems wrong… I went back into the GeoServer history and the oldest version I have on disk, 2.10, does not show this problem. So it seems like a regression.
Generally speaking, the page seems to be missing the workspace authorizer… however I can tell that 2.10 did not have it, and it was working anyways.
A few questions:
Anyone was already aware of this and had a look previously?
Do you know if this was for some reason an intended change?
What about just adding the component authorizer for the service pages? That seems to do the trick, at least partially, the global service configs are not visible but the workspace ones can be edited. However, if one uses a direct URL to the global service page, that works too, which is a no-go, but maybe just a fix needed in the authorizer.
I was not aware of this, and do not believe it would be an intended change.
I was working in this area recently to ensure layer services links on the welcome page respected workspace enablement and disablement settings.
Any user interface approach I contender is a little awkward.
The option of going through workspace editor link is okay, what is shown for page navigating when editing workspace WMS? I guess nothing. If this is easy to do then we can use this approach to fix the problem.
Option: Show the WMS Service page link, but only show the page by workspace chooser until they select a workspace the user can edit. Or show everything and only enable the fields when workspace is selected (so user can see configured default).
Option: Welcome page has a workspace chooser, only show the service page navigation when workspace is selected. Hide the when global is selected.
I’ve done some bisection search, the last version it works is a 2.13.x, it stopped working in 2.14.0… I cannot see any intended change in the changelog, maybe a side effect of some other change then (there is a bump in Spring security from 4.0 to 4.2 for example).
Anyhow, the issue has been around for more than six years.
Yes indeed, but it has likely nothing to do with the topic of being able to edit a service configuration as a workspace admin
(GUI permissions are quite different from service ones).
Hi all,
going back on this topic, I’ve found a way to make the workspace administrator access the per workspace service configurations.
However, after thinking about it a bit more, I grew doubts about it… in that, there are settings in the panel that belong to a per workspace service, like metadata style settings:
And others that related to the stability of the whole server… I’m not sure we want them to be editable by a workspace admin, like service limits (max memory per request), whether or not transactions are acceptable, the size of the WPS thread pools, maybe the OGC APIs conformance classes, and so on.
Addressing this is not trivial, the pages are not designed to have two sets of components for two different levels of accesses. Going there is a major amount of work, each service has a lot of settings, and for some the decision is more nuanced (e…g, the list of supported output formats).
Thinking out loud, should we have a simple flag enabling workspace admins to access the workspace services, or not, and it’s the full admin conscious decision whether to trust the workspace admins, or not?
That would be the ideal solution… if I had budget to go through all the fields for all the services, and mark them as “global admin” or not, and then make optional panels around each one of them. Not to mention all the fields that would be in a gray area, unclear whether they are meant for global or workspace admin.
And then there are the pluggable panels that show up only when certain plugins are added.
You surely understand how much work that would be, compared to what I proposed it’s well over an order of magnitude more expensive.
It would be a problem if the small implementation I proposed would impede
the fine tuned effort you ask about down the line, but I don’t see it happening.
I’d appreciate very much if you’d consider resourcing every time you come with a scope expanding proposal, especially when the extra effort is not a few percentage points… or just jump on board and say “yeah, I want more and I’m prepared to add the extra effort myself”.
First up I agree should we have a simple flag enabling workspace admins to access the workspace services (this could be a global setting or an application property not sure which is more appropriate).
Second I have been growing frustrated with the lack of feedback when the UI is displayed but ignore, such as application property is overriding the UI, or in this scenario where admin permissions is required.
Rather than hide (which is too much work) the suggestion is that we disable preventing interaction by workspace admin:
This would offer a minimal protection from casual workspace admin change.
Third: I am willing to do work - if the “disable service controls” approach is acceptable, but do not wish to put it as a blocker on your “simple flag” which can be accomplished ahead of 2.27.0 release.
Context: I recently made an optional panel for layer services when application property org.geoserver.service.disabled has been supplied - and agree that would be too much work … which is why I just proposed disabling controls above.
Hi,
summarizing from the discussion, so that we can move to implementation:
We’ll have a flag to allow a workspace admin editing the per workspace service configurations
When enabled, the behavior will be to mimic pre-2.14.0, the whole page is editable
When disabled, the links from workspace to the service configuration will be disabled and pages not accessible (not even with a direct link)
To enable/disable this, we could have a GUI flag in the Global Settings:
However, if anyone feels like adding support for conditional editing of the service page contents in the short term
(going over field by field) then maybe a system variable may be a better temporary solution.
Discarded due to excessive effort: conditional editing of service pages settings, be it by making the fields
read only, or hiding them, as the amount of unique settings, the decisions to be made with the community
regarding each one of them, the implementation cost of guarding each one, and having service code
pick the global vs workspace service depending on the field it wants to use, would be too big.
