-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Description
Possibly related: #36591 #50892
At the moment we have 3 special realms for which we do extra configuration that doesn't use the global Settings object.
- We always add a reserved realm, unless it is disabled (through an undocumented config that sitso utside the realm chain).
- We add a native realm and a file realm if there are no other enabled realms (other than reserved).
I would like to consider moving all of that config into the Settings object, by implementing it in Security.additionalSettings().
In that method we would:
- If the YML settings does not include a reservered realm, add one, with order
Integer.MIN_VALUE - If the YML settings does not include a file realm, add one, with order
Integer.MIN_VALUE + 1 - If the YML settings does not include a native realm, add one, with order
Integer.MIN_VALUE + 2
When we consider whether the settings includes a realm, we would treat enabled: false as being an included realm, so you could explicitly disable any of those 3 realms by adding them to the YML, and setting enabled to false.
This would mean that the node's settings always reflect the actual realm chain.
It would remove the magic setting to disable the reserved realm, and cases where the reserved realm was disabled would be just like any other disabled realm.
We would probably also want to add a validation in Realms to check that the reserved realm had the lowest order, and fail if it didn't.
We'd need to think about how this might work with dynamic realm configuration, but it potentially makes it easier by making all the realm stuff be done through Settings - it would just required that dynamic node config loading and additionalSettings played nicely together.