GeoServer does not load settings of a protected workspace when using Catalog Mode == Mixed
Steps to reproduce:
Add a role "testrole"
Add a workspace "testworkspace"
Add the following data access rules:
and assign these rules to the role "testrole"
Restart GeoServer and have a look at the log file. There is a stack trace caused by
As a consequence, GeoServer does not load the workspace settings for "testworkspace" and falls back to the default values. Unfortunately there is no indicator on the admin GUI that something went wrong.
A debug session shows that GeoServer uses the SecureCatalog implementation during bootstrapping. During this phase is the current user is null (treated as anonymous).
1) Is it possible to use the non secure implementation of the catalog during bootstrapping
2) If not, does it make sense to boostrap as "admin" or even better as "root" user.
Using the non secured catalog might work, there is the issue of not opening up paths for privilege escalation attacks though, as the REST API in general can be used by non full admins. The bootstrap as admin might seem a better idea, if you can ensure the authentication only lasts during the startup, and it's not involved in any other operation (e.g, catalog reload later, for example).
Would something like this be an acceptable solution
(Sorry about the former attempts, trying to learn Jira formatting....)
It seems like it would work, yes, isBootstrapping would be true only once no?
Yep, isBootstrapping is true only once.
Can you give me an hint where to look for the start of the the bootstrap sequence.
That is controlled by Spring, which instantiates beans the order it prefers (following dependencies of course). I'd suggest to put a breakpoint in the place where it breaks now and see.