You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is split into four distinct parts: (One commit is only performing a
clean up)
### 1. EmbeddedWeb: Explicitly perform authentication
It is nowadays no exception that stylesheet may be dependent on who's
using the app. So to avoid race conditions like in
#5385 authentication is an
explicit step during bootstrap now.
`EmbeddedWeb` now knows about and is responsible to initially set up the
user object. So this does not change when `Web` sets up the user, it
just allows `EmbeddedWeb` to do it.
A small side-effect introduced by this change is fully optional, but
doesn't break anything either: Method `Web::setupSession()` and the
accompanying `Web::$session` property are gone now as the property was
obsolete already. Initializing the session is still done at the previous
stage though, but implicitly by `Web::setupNotifications()`.
### 2. Auth: Perform authentication only once and not lazily
Since authentication is now performed even for static resources, there's
no reason anymore to support implicit authentication. This also limits
authentication attempts to a single one, previously failed attempts were
repeated. Requiring authentication during bootstrapping, i.e. before
authentication has been performed, will now throw an error.
This conflicts with #5430 as it also affects `Auth::isAuthenticated()`.
But this should be easy to resolve.
### 3. Manager: Perform module loading asynchronously
So that authentication can suspend it. There are cases, e.g. cube, where
authentication is required in run.php. During bootstrapping loading
modules is mostly required to load libraries, register routes and hooks.
Most of the time authentication is not required for these, but if it is,
evaluation is now interrupted and continued after authentication has
actually been performed.
I don't see a real risk for any breaking change here, since
authentication happens shortly after. It actually avoids a breaking
change, since without this, cube's Icinga DB support would break or at
least malfunction.
And cube is only a single example. As long as the *monitoring* module is
still supported by them, they will keep being affected.
Enable the *monitoring* module and Icinga DB Web in an environment and
look at the debug log to see this change in effect.
### 4. Module: Expect user and group backends upon registration
Providing a user or user group backend in configuration.php now triggers
a deprecation or warning. They are expected to be announced in run.php,
just like hooks. Authentication attempts during a configuration.php run,
while Authentication has not been performed yet, will be also suspended
now. This ensures that the current behavior, being broken or working,
stays the same.
You might think that this is a breaking change, but it was rather always
broken and only worked in such particular situations that custom
backends were never used in conjunction with any of the official modules
mentioned in 3.
Removing the compatibility layer (the suspension part) with v2.15 might
indeed be a bit hasty. But I rather like to get rid of this as early as
possible and I think those who have custom extensions like this, in a
functional state, are a minority and known to us. (i.e. Icinga partners
which we can forewarn)
0 commit comments