Feature/force fe user change pw on login

[ralfhartmann]

Der Nutzer kann jetzt zum Passwortwechsel gezwungen werden.

Solange der Nutzer den Haken an pwChange hat, wird FrontendUser::authenticate() den Nutzer ablehnen, außer zur Eingab des neuen Passworts, inkl. Kontrolle auf "schon mal benutzt". Hier kann man das noch ausbauen, z. B. im BE konfigurierbar machen, wie lange die alten PWs nicht benutzt werden dürfen, ModuleLogin ist dafür "vorgerüstet"
Wenn der Nutzer es geschafft hat, sein Passwort zu ändern, geht's weiter, wie bei Login (Weiterleitung ja/nein/Nutzergruppe).

Da die Konstante FE_USER_LOGGED_IN schon von index.php gesetzt wird, werden alle Funktionen, die zur Authentifizierung dies Konstante nutzen (und nicht FrontendUser::authenticate()) nicht merken, dass der Nutzer eigentlich sein Passwort ändern soll. Solange das Passwort-Ändern-Formular des ModuleLogin eingeblendet ist, und noch ein Request weiter wird FE_USER_LOGGED_IN true sein.

Da der Nutzer um dahin zu gelangen sein altes Passwort eingeben musste, ist das meiner Meinung nach nicht so schlimm.

[aschempp]

Was passiert wenn der Benutzer auf eine andere Seite navigiert (durch Eingabe der URL)?

[ralfhartmann]

Beim ersten Mal ist FE_USER_LOGGED_IN true, wegen dem Formular. Falls der Nutzer dies übertragen hätte, dürfte er nicht vorher durch index.html ausgeloggt werden, damit das neue Passwort gespeichert wird.

Wenn der Nutzer einfach was anderes anklickt oder eine URL eingibt, ist eben beim ersten Mal FE_USER_LOGGED_IN true, danach ist es false und der Nutzer ist wieder ausgeloggt. Also einmal kann er sozusagen noch eine für alle gesperrte, aber für ihn sichtbare Seite sehen.

Wie schon erwähnt, meines Erachtens nicht so schlimm, der Nutzer musste sich ja einloggen, um FE_USER_LOGGED_IN auf true zu bekommen. Die FrontendUser::authenticate() wird immer false liefern, solange tl_member_pwChange = 1.

Eine andere Möglichkeit zum Passwortänderungszwang wäre den Login komplett zu verbieten (ist in der Datenbak schon vorgesehen) und ein "Passwort-Ändern-Mit-Angabe-des-Nutzernamen-und-Alten-Passworts-und-Zwei-Mal-Neues-Passwort"-Moduls.

[leofeyer]

Ich finde nicht, dass wir das im Core brauchen. Im Backend ist das etwas anderes, weil hier die Passwörter vom Administrator generiert werden, aber im Frontend legt das Mitglied sein Passwort selbst fest, daher wäre es IMHO ausreichen, wenn man die Funktionalität optional per Extension nachrüstet.

[AgentCT]

Ich hatte leider ein neues Posting aufgemacht aber ich bin auch dafür, dass man diese Funktion anbieten sollte.

Jeder kann sich doch denken, dass nur die wenigsten User ein Passwort ändern, wenn man als Administrator einen Account für einen User angelegt hat.

Aus meiner Sicht wäre es eine Funktion die in den Core gehört und nicht in eine seperate Extension.

[leofeyer]

Wir besprechen das am besten mal in größerer Runde. @contao/developers

[leofeyer]

We have briefly discussed this in Mumble on January 26th, and we need to wait with implementing this until we have switched authentication to Symfony security.

[leofeyer]

@contao/developers We now have Symfony security, so how do we proceed with this?

[aschempp]

Kinda related to the IS_FULLY_AUTHENTICATED discussion we had. There's no frontend page we can redirect when the password needs to be changed.

[leofeyer]

The page can be set in the module settings, can't it?

[aschempp]

Not really, if we must prevent the user from accessing any other site in the page tree before he has changed the password.

[leofeyer]

True.

[Toflar]

Stay on the same page and let the login front end module handle the confirmation? Would that work?

[aschempp]

Not really. As I wrote, the user can always navigate away and therefore bypass the password change.

[Toflar]

Yeah we need an intermediate state. Something like "Password ok but needs to be changed" which means they are not logged in yet. So when they navigate away, they're logged out.

[leofeyer]

As discussed in Mumble on September 27th, we want to try to implement this in the login module.