Files
projectsend/app/Modules/Identity/Http/Middleware/EnforceTwoFactor.php
T
ignacionelson ff9ad10742 Let an account that signs in through a provider set a password
Reported by Ricardo Cazati, who had to turn compulsory two-factor off to
get his colleagues working.

An account provisioned by a provider carries a generated password nobody
has ever seen. The password screen asked for the current one before it
would set a new one, so those accounts could never have a password of
their own — and enrolling in two-factor is behind a password
confirmation, so they could not enrol either. With
`TwoFactorEnforcement` set, the enforcement middleware sent them to
enrol, enrolling sent them to confirm a password they do not have, and
every other screen — including the one that would have given them one —
redirected back. No way in and no way out.

- The password screen asks for the current one only where there is one,
  and says "Set a password" otherwise. Setting it moves the account to
  `local`, the line NewPasswordController already writes when such an
  account resets its password: the hash is now what signs it in, and the
  settings screens read that off this column.
- An LDAP account is refused outright rather than handed a password that
  signs nothing in — its password lives in the directory.
- The enforcement middleware lets the password screen through, the way it
  already lets the confirm-password screen through, so the loop has an
  exit.
- The confirm-password screen offers to set one instead of asking for a
  password that does not exist.
2026-09-18 13:16:20 -03:00

67 lines
2.6 KiB
PHP

<?php
declare(strict_types=1);
namespace App\Modules\Identity\Http\Middleware;
use App\Modules\Identity\TwoFactor\TwoFactorEnforcement;
use App\Modules\Platform\Settings\Setting;
use App\Modules\Platform\Settings\Settings;
use App\Support\WriteSafeRedirect;
use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;
/**
* When the installation enforces two-factor authentication for the
* user's type, an un-enrolled user can only reach the 2FA setup screen
* (and the exits: logout, locale) until they enable it.
*/
class EnforceTwoFactor
{
public function __construct(
private readonly Settings $settings,
) {}
public function handle(Request $request, Closure $next): Response
{
$user = $request->user();
if ($user === null || $user->hasTwoFactorEnabled()) {
return $next($request);
}
$value = $this->settings->get(Setting::TwoFactorEnforcement);
$enforcement = (is_string($value) ? TwoFactorEnforcement::tryFrom($value) : null)
?? TwoFactorEnforcement::None;
if (! $enforcement->appliesTo($user->type)) {
return $next($request);
}
// password.confirm* is on this list because the two-factor mutation
// routes now require it: without the exemption, enrolling would
// redirect to the confirm-password screen, which this middleware
// would redirect straight back to two-factor.show — a loop that
// locks the user out of the only exit.
//
// The pattern covers both halves of that screen. Naming only the
// GET left the form rendering and its submission redirected away,
// so the password was never confirmed and the loop stayed shut
// one step further along than before.
// password.edit/update is on it for the same shape of reason, one
// step further out: an account provisioned by a provider has no
// password to confirm with, so the confirm screen sends it to set
// one — and without this, that screen was redirected back here
// too. The loop then had no exit at all, which is how an
// installation that made two-factor compulsory locked out
// everybody who signs in with Microsoft.
if ($request->routeIs('two-factor.*', 'password.confirm*', 'password.edit', 'password.update', 'logout', 'locale.update')) {
return $next($request);
}
return WriteSafeRedirect::apply($request, redirect()->route('two-factor.show')->with('two_factor_enforced_notice', true));
}
}