mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-20 18:43:20 +00:00
ignacionelson
ff9ad10742
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.