Passwortverwaltung / Password management

[LeAchim59]

Die Passwortverwaltung für Mitarbeiter und Nutzer ist veraltet. Die Passwörter werden teilweise unverschlüsselt in der Datenbank abgelegt und sind für die jeweiligen Benutzer nicht selbst änderbar.

Für mich wären die Mindestanforderungen:

• Passwort in Datenbank verschlüsselt
• Regeln für Passwort: >= 8 Zeichen, mind, eine Ziffer oder Sonderzeichen
• Da sich die Benutzer nicht selbst registrieren können, muss direkt nach der Anmeldung eine Email mit einem zufällig erzeugten Passwort an den Benutzer, die ihn auffordert, sein eigenes Passwort einzugeben.
• Möglichkeit zur Rückantwort zeitlich befristen, danach muss der Benutzer ein neues Passwort anfordern.
• Funktion: Passwort vergessen (ist aber im Prinzip das gleiche wie nach Neuanmeldung)

Dass ein neuer Benutzer das Passwort bestätigen muss, dient zugleich der Verifizierung der Email-Adresse. Wir haben immer wieder fehlerhafte Email-Adressen (auch weil die Leute das Anmeldeformular nicht leserlich genug ausfüllen). Optional könnte man die Ausleihe auch sperren, solange die Emailadresse nicht durch verifiziert wurde.

---

Password management for employees and users is outdated. Some passwords are stored unencrypted in the database and cannot be changed by the users themselves.

For me, the minimum requirements would be

• Password encrypted in database
• Password rules: >= 8 characters, at least one digit or special character
• As users cannot register themselves, an email with a randomly generated password must be sent to the user immediately after registration, prompting them to enter their own password.
• There is a time limit for replying, after which the user must request a new password.
• Function: Forgotten password (but is basically the same as after a new login)

The fact that a new user has to confirm the password also serves to verify the email address. We often have incorrect email addresses (also because people do not fill out the registration form legibly enough). Optionally, you could also block the loan as long as the email address has not been verified.

[375michael40veit]

Ich kann bis etwa Anfang Mai ausgehend von meiner Version für die neue Original-Version Folgendes entsprechend entwickeln:

• Bei Login --> Abgleich, ob unverschlüsselt (Nutzer) oder mit md5 (Mitarbeiter) verschlüsselt ist,
• Bei erfolgreichen Login wird dass Passwort durch password_hash verschlüsselt und in die Datenbank hinterlegt.
• Regeln für Passwort: >= 8 Zeichen, mind, ein Groß- und ein Kleinbuchstabe, eine Ziffer und ein Sonderzeichen
• Sollte wahrscheinlich auch gut möglich sein: Nutzer können selbst ihr Passwort ändern.

Wenn ich nichts mehr anderweitiges höre, gehe ich davon aus, dass ich dies so entwickeln kann.

---

I can develop the following for the new original version based on my version by around the beginning of May:

• At Login --> Check whether it is unencrypted (user) or encrypted with md5 (employee),
• If the login is successful, the password is encrypted with password_hash and stored in the database.
• Rules for password: >= 8 characters, at least one upper and one lower case letter, one number and one special character
• Should probably also be possible: Users can change their password themselves.

If I don't hear anything else, I assume that I can develop this in this way.

[LeAchim59]

@375michael40veit Hallo Michael (?), das klingt im Ansatz schon mal gut und sind die Grundlagen. Das heißt aber erst mal für Nutzer und für Mitarbeiter, sie müssen bei der Anmeldung weiterhin ein Passwort angeben, das dann immerhin verschlüsselt in der Datenbank abgelegt wird. Ich nehme an, Deine Vorstellung des Passwort änderns laufen erst mal darauf hinaus, dass man es ändern kann, wenn man angemeldet ist. Wäre prima, wenn Du das angehst.

Bisher ist das Passwort für Nutzer optional über ein evtl. vorhandenes benutzerdefiniertes Feld "secret". Ich würde bei der Gelegenheit die Tabelle member und die dazugehörige Klasse um ein entsprechendes Feld Passwort erweitern.

Die Funktion "Passwort vergessen" kann man ja dann im nächsten Schritt angehen. Danke und Grüße Michael

[Larian77]

Hi Klingt gut, ich würde aber gerne bevor wir beginnen erstmal die 0.8er Version veröffentlichen :) Für diese Funktionen müssen wir auf alle Fälle an die DB ran und hier ist es dann wichtig immer gleich ne Upgradeversion und auch ne neue Installationsfunktion für die neue DB-Version mitbauen entwickeln :)

[LeAchim59]

Hallo Marcus, Du hast natürlich recht, erst mal die 0.8er Version zu veröffentlichen. Aber das steht ja mehr oder weniger unmittelbar bevor (wir haben jetzt eine Testinstallation der Version und ich habe unsere Anwender mal zum ausführlichen Test eingeladen). Aber das muss die frisch motivierten Entwickler ja nicht davon abhalten, neue Funktionen im eigenen Fork zu entwickeln. Ich habe übrigens mit der Update-Routine angefangen, die benötige ich ja mehr oder weniger sowieso am Anfang, um die bestehende Datenbank um die neuen Datenstrukturen zu erweitern ;-)

[375michael40veit]

Hallo LeAchim59, ich werde erstmal es so programmieren, dass (noch) keine Änderung an der DB-Struktur notwendig ist. Dies kann man dann bei Bedarf angehen, wenn die Update-Routine steht. Ein Passwort ändern ist nach Login dann möglich. Viele Grüße Michael

---

Hello LeAchim59, I program it so that no changes to the DB structure are necessary (yet). This can then be done if necessary when the update routine is ready. A password change is then possible after login. Best regards Michael

[LeAchim59]

Hallo Michael,

das ist natürlich erst mal OK, die Feldgrößen in staff und als benutzerdefiniertes Feld geben das her. Ich finde es allerdings etwas unglücklich, weiterhin mit dem benutzerdefinierten Feld "secret" für eine Kernfunktion zu arbeiten. Ich halte die Verwendung eines Passworts für den Nutzerlogin heutzutage nicht mehr für optional sondern unbedingt erforderlich.

Die Update-Routine der Datenbank an sich ist ja nur eine Zeile SQL, die das Feld der Tabelle member hinzufügt. Viel aufwendiger ist dann die Umsetzung der vorhandenen Passwörter in bestehenden Datenbanken in das verschlüsselte System. Diese Routine muss dann ja einmalig über alle member- und Staff-Datensätze schleifen und die bestehenden Passwörter verschlüsseln.

viele Grüße Michael

[LeAchim59]

@375michael40veit Hallo Michael, https://www.php-einfach.de/experte/php-codebeispiele/loginscript/passwort-vergessen/ da findet sich der Code für die Funktion Password verlängern. Den müsste man wohl nur an unsere Datenbanktabellen anpassen bzw. so, dass er für Staff und Member verwendbar ist. Kannst Du Dir ja mal bei Gelegenheit anschauen.

[LeAchim59]

Dort gibt es auch einen interessanten Artikel, wie man Passwörter sicher speichert: https://www.php-einfach.de/experte/php-sicherheit/daten-sicher-speichern/

[375michael40veit]

@Larian77 @LeAchim59 Von der Entwicklung bin ich schon ziemlich weit fortgeschritten. Es sind noch ein paar Kleinigkeiten zu programmieren, ein paar Tests durchzuführen und unnötigen Programmier-(Test-)Code zu entfernen. Die Passwort-Verschlüsselung habe ich generell mit password_hash versehen. Dies macht jedoch folgende DB-Änderungen notwendig. table staff --> column pwd --> Typ-Änderung auf varchar(255) table member_fields --> column data --> Typ-Änderung auf mediatext

Folgendes wird zurzeit umgesetzt:

• Bei Login --> Abgleich, ob unverschlüsselt (Nutzer) oder mit md5 (Mitarbeiter) verschlüsselt ist,
• Bei erfolgreichen Login wird dass Passwort durch password_hash verschlüsselt und in die Datenbank hinterlegt.
• Regeln für Passwort: >= 8 Zeichen, mind, ein Groß- und ein Kleinbuchstabe, eine Ziffer und ein Sonderzeichen
• Mitglieder können selbst ihr Passwort ändern.

Was noch geklärt werden sollte:

• Wie weit steht schon die allgemeine Update-Routinen, auf die man dann die entsprechenden DB-Änderungen laufen lassen kann?
• Oder soll ich die notwendigen DB-Update-Routine und die neue 0.8.1-DB-Install-Version noch nach altem Muster aufbauen?
• Soll die Verschlüsselung der Member-Passwörter ausschließlich über die Update-Routine durch eine neue Openbiblio-Version geschehen oder soll die Verschlüsselung parell, sprich entweder über Login oder/und über Update-Routine, laufen? Nach jetzigem Stand sollten beide Varianten umsetzbar sein.
• Da die Staff-Passwörter mit md5 verschlüsselt sind, ist hier eine Änderung von md5 auf password_hash nur über die jeweiligen Logins möglich, da md5 nicht direkt entschlüsselt werden kann.

Über Rückmeldung von Euch bin ich dankbar, um die Programmierungen entsprechend ausrichten zu können. Ich würde bei Abschluss den branch bei mir veröffentlichen, dann könnt Ihr ihn als eigene Testversion testen. Es sind einige Änderungen und ein paar Dateien dazugekommen.

Die Passwort-vergessen-Funktion könnte ich dann im Nachgang noch miteinbauen.

Viele Grüße Michael

[LeAchim59]

Hallo Michael, Warum das member-Passwort optional ist, weiß ich nicht. Wahrscheinlich wollte man da gerade auch nicht die Datenbankstruktur verändern. Wenn es aber sowieso gerade geschieht, dann würde ich die Tabelle member um das Passwortfeld erweitern und "secret" nicht mehr benutzen.

Meinst Du mit "Mitglieder können selbst ihr Passwort ändern." staff oder member?

Es gibt noch keine Update-Routine für DB_0.8.1: Vielleicht kann @Larian77 was dazu sagen. Ich bin in Sachen PHP und Webentwicklung völliger Neuling. Ich wüßte auch gar nicht, wie man es anders machen kann, als es hier bisher lief.

Ich würde das Umsetzen der Member-Passwörter einmalig beim Update machen. Wenn man "secret" abschafft, muss man sowieso umsetzen und das Feld "secret" gleich löschen. Damit ist dann auch kein Code zur Umsetzung in der regulären openBiblio-Version, der dann ewig mitgeschleppt werden muss.

Staff sind ja i.d.R. eine übersichtliche Anzahl an Leuten. Ich würde da auch kein dynamisches Umsetzen beim Login machen (wie gesagt, man schleppt unnötigen Code mit sich rum) und wäre für einen harten Schnitt. Entweder sie müssten beim Admin ihre Passwörter neu hinterlegen oder besser über Passwort vergessen neue anfordern. Das ist zumutbar. (ich glaube, bei unserer Mitarbeiterliste würde sich bei der Gelegenheit gleich einiges bereinigen ;-) )

vielen Dank für die bisherigen Mühen und viele Grüße Michael

[Larian77]

Die ursprüngliche Intention war, dass die DB-Struktur in der deutschen Version nicht geändert werden sollte, damals gab es ja noch die englische Oroginalversion und die deutsche Version sollte kein Fork werden und sobald man DB-Änderungen macht haben wir Probleme kompatibel zu bleiben (hatte ich am Anfang mal die böse Erfahrung gemacht) Daher das secret nur als "workaround" und dieses nur optional, damit wir ohne DB-Änderung einen Weg finden.

Da das Originalprojekt ja aber nun tot ist können wir nun auch DB-Änderungen machen.

Was wichtig ist, dass trotzdem der User ja ein Initialpasswort bekommt, das der Verleiher ja normalerweise auch kennt/sieht, weil der User normalerweise nicht in der Ludothek an den Computer kommt, danach kann dieses natürlich vom User änderbar/vom Verleiher nicht mehr einsehbar sein.

Updateroutinen habe ich noch gar nicht angefangen, weil es bisher keine DB-Änderungen gab, es gibt unter https://github.com/Larian77/Openbiblio/discussions/20 schon mal eine Doku welche DB-Felder mir alles einfallen, die man im Update mal beachten sollte, weil sie bisher nur in der Anleitung als selber zu ergänzen beschrieben sind. Grundsätzlich kann die Updateroutine neu gemacht werden oder so, wie sie bisher läuft, da bin ich offen.

Das Update der Passwörter User secret auf password-hash-DB sollte denke ich mit dem Update passieren, eine Rücksetz-/Erinner-Funktion sollte mit rein, weil die User oft ihr PW nicht mehr wissen.

Beim Staff gerne wie Michael beschrieben hat, aber wir brauchen hier trotzdem (entweder beim Update oder anders) eine Möglichkeit wie der Admin sein PW updatet, wir müssen wir gesagt davon ausgehen, dass wir User haben die von der Technik dahinter keine Ahnung haben.

[Larian77]

Ah ja und hier in der Version gerne das Suspend - wobei ein Autosuspend mir nicht gefällt, das nutzt keine Software mehr weil es für User einfach risikobehaftet ist, dass jemand das ausnutzt um Accounts zu zerstören. Sauber wäre eigentlich ein Logeintrag in einem logfile (wegen mir auch syslog), den man dann mit zB fail2ban selber auf dem Server abfangen könnte

[LeAchim59]

@Larian77 Da ein User bisher nicht selbst sein Initialpasswort einträgt, wäre für mich die Ideallösung wie das inzwischen sonst so üblich ist, dass der Benutzer eine Begrüßungsmail bekommt und dann über einen entsprechenden Link (wie bei Passwort vergessen) sich das Passwort selbst eintragen kann. Das hat zudem den Vorteil, dass man gleichzeitig die angegebene Email-Adresse verifiziert. Zum Admin; Letztendlich ist der admin ja auch ein Benutzer wie alle anderen. Vielleicht hat er den direkten Zugriff auf den DB vielleicht auch nicht. Wenn es eine Passwort-vergessen-Funktion gibt, kann der admin sie notfalls auch verwenden. Ich sehe immer mehr, dass wir mit dieser Funktion so einige Probleme erschlagen können. @375michael40veit: wäre wirklich toll, wenn Du das auch noch hinkriegen würdest.

[Larian77]

Bei uns wird im Aufnahmeformular für User das Passwort bisher abgefragt, d.h. der User legt es selber fest und wir tragen es ein (derzeit)

Problem was ich gerade mit der Erinnerungsfunktion sehe: die Staff-Einträge haben alle keine Mailadresse, wo soll die Erinnerung hingehen? Kann man beim Update ja ergänzen, aber direkt nach dem Update gibts da nicht wohin der Admin die Erinnerung bekommen könnte :-(

[LeAchim59]

Das mit der Passwortangabe bei neuen Usern kann man durchaus erst mal so lassen. Mein Wunsch ist es halt, auch die angegebene Email-Adresse zu verifizieren, wir haben da doch eine nicht unerhebliche Fehlerquote. Und da wir über Email mahnen, ist das blod, wenn man erst dann feststellt, dass der Kontakt nicht da ist. Wenn der Fehler direkt nach der Anmeldung auftaucht, kann man direkt bei der nächsten/ersten Ausleihe nach der korrekten Emailadresse fragen.

Bei den Staff-Einträgen habe ich die Emailadresse auch schon vermisst. Sollte man gleich mal vorsehen, Die fehlende Mailadresse ist tatsächlich dann ein Problem beim Update. Für die Mitarbeiter hiesse das beim Update: Vor dem Update muss der Admin alle Emailadressen einholen (sofern er sie nicht sowieso schon hat). Dann Update ohne Passwort, weil md5 ja auch nicht unbedingt decrypten lässt. Admin trägt alle Emailadressen ein und dann können die Mitarbeiter ein neues Passwort anfordern. Der Aufwand sollte sich in Grenzen halten, ich denke wir haben mit 24 Mitarbeitern schon viele, oder?

[LeAchim59]

@375michael40veit Wenn Du schon an die Änderung der Tabellen member und staff gehst, um das "Passwort" einzutragen, lege doch bitte gleich ein Datumsfeld für den Timeout für Passwort vergessen an. Falls das dann später erst realisiert wird, dann ist zumindest das Feld schon mal da. Danke.

[375michael40veit]

Kurzer Zwischenbericht: Bisherige Arbeiten:

• Staff-Pwd wird durch Login von md5 mit password_hash umgewandelt. Ein zeitnahes Login der Mitarbeiter:innen kann m.E. erwartet werden. (Die automatische Aufforderung per E-Mail-Versand ein neues Passwort zu setzen, ist erstrebenswert, würde jedoch das Upgrade auf Version 0.8.1 m.E. zu lange nach hinten schieben.)

Erweiterung der DB-Tabellen per Installation oder Aktualisierung:

• DB-Tabelle staff --> Erweiterung mit den Spalten pwd_timeout und email
• DB-Tabelle member --> Erweiterung mit den Spalten pwd, pwd_timeout
• DB-Tabelle settings --> Erweiterung mit Spalte library_online --> Diese Einstellung ist notwendig, da manche das Programm ggf. nur als Verwaltungsprogramm ohne Zugriff der Benutzer auf ihr eigenes Konto verwenden. Sie müssten dann stets ein Passwort vergeben, obwohl dies nicht notwendig ist.
• Aktualisierung und Überprüfung der allgemeinen Installations- und Aktualisierungsroutinen für die Version 0.8.1

Zurzeit noch dran

• Umbau der bisherigen Programmierung von member_fields code='secret' auf member --> pwd. Hier komme ich gut voran, jedoch ist der Umbau noch nicht ganz abgeschlossen und veralteter Code muss noch entfernt werden
• Update-Routine: -- Überprüfung, ob noch notwendig bzw. Aufnahme der Inhalte von @Larian77 in die Datenbank bei der Aktualisierungsroutine auf 0.8.1 -- Kopieren des Passwortes von member_fields zu member --> pwd, bei gleichzeitigem Umwandeln des Passwortes mit password_hash -- Nach erfolgreichem Kopieren der Passwörter --> Löschen der code-Felder 'secret' in member_fields und member_fields_dm
• Umsetzung des Timeouts bei mehrmaliger falscher Eingabe des Logins. Dies sollte nun leicht umzusetzen sein.

Danach werde ich den branch zum Testen veröffentlichen.

Der Einbau der Passwort-Vergessen-Funktion kann dann im Anschluss erfolgen.

[Larian77]

Danke, ja, bin auch für die Methode des automatischen Umwandelns beim Login, müssen ja auch Kompatibilität voraussetzen, eine Zwischenversion bringt nichts, wenn jemand Versionen überspringt.

Habe jetzt das Bugfix veröffentlicht mit Beheben der kleinen Bugs, dort habe ich das Suspend aber erstmal wieder rausgenommen.

Wenn wir eh die DB und die Settings erweitern können wir in der Version dann später auch noch https://github.com/Larian77/Openbiblio/issues/11 integrieren.

[LeAchim59]

Hallo, natürlich kann ich auch mit dem automatischen Umwandeln des Codes leben. Eine vermiedene Umsetzung aller Passwörter auf einmal, kann aber kein Argument sein, dass man im Update-Prozess eine Version überspringen kann. Man muss immer alle Datenbankänderungen um damit verbundene Umsetzungen aller Versionen, die man überspringt, nachziehen. Die Update-Routinen sind auch bisher so programmiert: Es werden alle Anpassungen durchgeführt, die nötig sind, um vom Ausgangszustand auf die aktuelle Version zu kommen. Vielen Dank an Michael für die Mühe.

[LeAchim59]

@375michael40veit Was ich aber nicht verstehe, warum Du die Option "library_online" benötigst? Wenn das Passwort eines members weiterhin optional ist und er sich dann halt nicht anmelden kann, ist die Option m.E. nicht nötig.

[Larian77]

Hallo, natürlich kann ich auch mit dem automatischen Umwandeln des Codes leben. Eine vermiedene Umsetzung aller Passwörter auf einmal, kann aber kein Argument sein, dass man im Update-Prozess eine Version überspringen kann. Man muss immer alle Datenbankänderungen um damit verbundene Umsetzungen aller Versionen, die man überspringt, nachziehen. Die Update-Routinen sind auch bisher so programmiert: Es werden alle Anpassungen durchgeführt, die nötig sind, um vom Ausgangszustand auf die aktuelle Version zu kommen. Vielen Dank an Michael für die Mühe.

Ich meinte nur die Variante: erst ein Update rausgeben wo man die Mailadressen einpflegt und danach ein Update was die Passwörter per Mail zurücksetzt wenn dann die Mailadressen vorhanden sind wie zwischendurch vorgeschlagen :-) - das ist eher schwierig

[LeAchim59]

Ich meinte nur die Variante: erst ein Update rausgeben wo man die Mailadressen einpflegt und danach ein Update was die Passwörter per Mail zurücksetzt wenn dann die Mailadressen vorhanden sind wie zwischendurch vorgeschlagen :-) - das ist eher schwierig

Wie kommst Du darauf? ;-) Das ist doch wirklich umständlich und, wie Du bemerkst, ja auch nicht konsistent. Davon bin auch nie ausgegangen. Die Anwendung muss in sich schon konsistent sein, der Status einzelner Benutzer kann aber unterschiedlich sein. Dabei gibt es halt grundsätzlich zwei Methoden: a) man schleppt die alte Methode weiter im Code mit, hier eben das alte md5-Passwort prüfen und erst bei erster Anwendung umsetzen oder b) eine radikale Umsetzung, wo jeder sofort aktiv werden muss. Michaels Weg, das bei Bedarf umzusetzen, ist ok. Wobei ich eben, wie schon geschrieben, bei der kleinen Zahl Mitarbeiter auch kein Problem hätte, radikaler vorzugehen (da würde ich auch mal sehen, wer von den 30+ Mitarbeitern überhaupt noch aktiv ist ;-) )

[375michael40veit]

Branch "Login_Timeout_Email_Update" unter dem Link "https://github.com/375michael40veit/Openbiblio/tree/Login_Timeout_Email_Update" zum Testen veröffentlicht. Folgendes wurde entwickelt:

• Bei Staff-Login --> Abgleich, ob md5 (Mitarbeiter) noch verschlüsselt ist,
• Bei erfolgreichen Login wird dass Passwort durch password_hash verschlüsselt und in die Datenbank hinterlegt.
• Regeln für Staff- und Member-Passwort: >= 8 Zeichen, mind, ein Groß- und ein Kleinbuchstabe, eine Ziffer und ein Sonderzeichen
• Members/Benutzer können selbst ihr Passwort ändern.
• Install- und Update-Routine entsprechend angepasst: -- Erweiterung der DB-Tabellen per Installation oder Aktualisierung: --- DB-Tabelle staff --> Erweiterung mit den Spalten pwd_timeout und email --- DB-Tabelle member --> Erweiterung mit den Spalten pwd, pwd_timeout --- DB-Tabelle settings --> Erweiterung mit Spalte library_online --> Diese Einstellung ist notwendig, da manche das Programm ggf. nur als Verwaltungsprogramm ohne Zugriff der Benutzer auf ihr eigenes Konto verwenden. Sie müssten dann stets ein Passwort vergeben, obwohl dies nicht notwendig ist. --- DB-Tabelle settings --> Erweiterung mit den Spalten für eine zeitlichen Ausschluss bei einer bestimmte Anzahl an Fehlversuchen: login_attempts und pwd_timeout -- Member-Geheimwörter --- Verschlüsseln der Geheimwörter und einsetzen in Tabelle member --- Löschen der Einträge bzgl. "secret" in den Tabellen member_fields und member_fields_dm -- Bei der Aktualisierung der Datenbank können die drei neuen Bibliothekseinstellungen vorweg eingestellt werden. Ansonsten stest über das Register "Admin" unter dem Link "Bibliothekseinstellungen".
• Hinzufügen entsprechender Dateien bzgl. Logout, Timeout, Maintenance
• Hinzufügen einiger Sprach-Strings, u.a. auch im Update-Prozess

Bitte die Datei ./install_instructions_german.html beachten, u.a. bei Neuinstallation bzgl. Kennwort für admin.

Die "Passwort vergessen"-Funktion ist noch nicht integriert. Ich habe mich damit noch nicht beschäftigt. Es sollte dabei Folgendes überlegt werden:

• Mailversand nur über php-Mail-Funktion oder auch über ein Mail-Konto mit entsprechender Verschlüsselung?
• Wenn (auch) über ein Extra-Mail-Konto, dann ist die Frage, wo diese Daten in der Datenbank gespeichert werden sollen. Intuitiv würde ich diese in die Tabelle 'settings' mit aufnehmen.
• Damit würde sich jedoch die Tabelle nun langsam, aber sicher in die Breite ziehen und ein anderes aufstellen der Einstellungen wäre zu überlegen, z.B. mit folgenden Spalten: id, description/code, data, ggf. auch old_data.
• Damit müssten wahrscheinlich manche Settings-Query angepasst werden.

[375michael40veit]

Ergänzend:

• Aufgrund der Passwort-Validierung muss stets ein entsprechendes Passwort vergeben werden. Durch die Einstellung "Library-Online" kann OpenBiblio auch ohne Online-Member-Zugriff verwendet werden, d.h. es müssen keine Passwörter bei Erstellung von neuen Members gesetzt werden.
• E-Mail-Validierung, d.h. es muss stets eine E-Mail-Adresse gesetzt werden. Dies ist durchaus sinnvoll bzw. notwendig, wenn wir die "Passwort vergessen"-Funktionn einführen wollen.

[LeAchim59]

Hallo Michael, ich habe mir Deinen Code grob angeschaut und schon verstanden, wie Du den Schalter "library-online" einsetzt. Ich denke aber immer noch, dass man ihn nicht benötigt. Man muss dann nur Anfragen von Member abweisen, wenn kein Passwort vorhanden ist, bzw. darauf hinweisen, dass man eines vom Admin anfordern muss. Ist ja im Prinzip jetzt schon so. Die Passwort-Validierung ist dann eben auch gültig, wenn kein Passwort vorliegt. @Larian77 : Was ist Deine Meinung dazu?

[375michael40veit]

@LeAchim59 @Larian77 Vielleicht muss ich noch etwas ausholen bzgl. des Einsatzes von "libryry_online"-Einstellung: Ist-Stand: Bei "Online-Kontozugriff für Benutzer" oder ohne library-online-Funktion muss aufgrund der Pwd-Validierung beim Anlegen eines neuen Benutzers durch die Mitarbeiter:innen ein Passwort gesetzt werden. Es kann nicht leer gelassen werden und muss den Anforderungen entsprechen: mind. 8 Zeichen, 1 Groß-, 1 Kleinbuchstabe, 1 Ziffer und 1 Sonderzeichen.

Szenarien:

• Die Original-Openbibio-Version sah kein Benutzer-Konto vor, in dem sich der Benutzer selbst anmelden konnte. Ich gehe davon aus, dass es noch (genügend) Anwender gibt, die Openbiblio so noch verwenden bzw. ggf. noch so verwenden wollen. Diesen Nutzerkreis möchte ich nicht verlieren. -- Szene 1: Openbiblio, rein als Vewaltungsprogramm: Als Anwender/Bibliotheksmitarbeiter nervt es mich, wenn das Programm Eingaben fordert, die nicht benötigt werden. Allein schon das Vorhandensein von unnötigen Feldern kann als störend empfunden werden (s. Diskussion von LeAchim599 https://github.com/Larian77/Openbiblio/discussions/31 ) -- Szene 2: Die Benutzer sollen per Internet sehen, was vorhanden ist, ob ausleihbar ist etc. Sie sollen jedoch keinen Zugriff auf ihr Benutzerkonto haben. Dieses Szenario ist ebenso sehr gut vorstellbar, da die Original-Openbiblio dies nicht vorsah und die deutsche Version dies auch nicht zwingend vorgab. --> Aufgrund der oben beschriebenen Pwd-Erfordernis werden die Bibliotheksmitarbeiter:innen zwangsweise ein Passwort hinterlegen müssen. Im schlimmsten Fall immer das selbe, um nicht noch mehr Zeit mit unnötigen Eingaben verbringen zu müssen. Damit wird jedoch eine Tür, sprich ein Login für die Benutzer ermöglicht, obwohl vom Anwender/Bibliotheksmitarbeiter gar nicht gewünscht.

Aufgrunddessen sehe ich das Häkchen als eine gute Lösung den veschiedenen Anwendungsszenarien am ehesten gerecht zu werden. Falls im Nachhinein, doch ein Onine-Zugriff für Benutzer:innen gewünscht wird, stellt dies auch kein Problem dar. Da die Eingabe eines leeren Passwort-Feldes nicht akzeptiert wird. Zurzeit bin ich dabei die Passwort-Vergessen-Funktion zu programmieren. Damit könnten dann Nutzer nicht nur ein neues Passwort neu setzen, wenn sie es vergessen haben, sondern auch, wenn sie noch keines haben, vorausgesetzt es ist im Profil eine E-Mail hinterlegt.

Dieses Szenarien zeigen meines Erachtesn gut auf, dass die library_online-Einstellung sehr wichtig ist für Anwender, die keinen Online-Zugriff für ihre Benutzer wünschen.

@LeAchim59: Gibt es von Deiner Seite noch andere Gründe, warum die library_online-Einstellung nicht sinnvoll ist, außer dass sie bzgl. Login nicht nötig ist.

[375michael40veit]

@Larian77 @LeAchim59

Zwischenstand bzw. Überlegungen zu Passwort vergessen-Funktion:

Auf Passwort vergessen-Seite wird es zwei Optionen bzgl. Passwort-Anforderung geben:

Eingabe der

• E-Mail oder
• Benutzernummer in seperaten Nutzerfelder eingeben. Begründung: Aufgrund der bisherigen Programmierung kann die Verwendung der gleichen E-Mail-Adresse bei verschiedenen Benutzerkonten nicht ausgeschlossen werden bzw. sind ggf. auch sinnvoll, z.B. Eltern- und Kinderkonto. Aufgrunddessen macht als einzigartiges Nutzerkriterium die Benutzernummer Sinn, um eine eindeutige Zuordnung zu ermöglichen. Sollten mehrmals die selbige E-Mail vorliegen erfolgt eine kurze Info und der Hinweis die entsprechende Benutzernummer einzugeben.

Mailversand

Auswahlmöglichkeit für Mitarbeiter:innen mit Admin-Rechte der zwei Varianten

• php-Funktion mail() oder
• phpMailer

Der zufällig erstellte String für URL und das sichere Zuordnen des anfragenden Users bzgl. Passwort neu setzen wird nicht per sha1, sondern mit sha2 verändert, damit jedoch auch etwas länger.

Die Passwort-Zurücksetz-Funktion wird nur eine bestimmte Zeit möglich sein. An dieser Stelle nochmals vielen Dank an @Larian77 für den Link bzgl. Passwort-vergessen. Dies war bzw. ist eine sehr gute Grundlage für die weitere Entwicklung für openbiblio.

Folgende Datenbank-Änderungen bzw. Neuerungen sind meines Erachtens sinnvoll:

• Erweiterung der Tabellen von staff und members mit den Spalten pwd_forgotten und pwd_forgotten_time
• Erstellen einer neuen Tabelle email_settings mit den Spalten: mail_process (mail() oder phpMailer), mail_host, mail_user, mail_pwd, mail_smtp_secure, mail_port
• Erstellen der Tabelle mail_messages mit den Spalten: mail_message_type (z.B. Passwort vergessen, Begrüßung, ggf. später Erinnerugsmail), mail_from, mail_subject, mail_body_html (als html bei phpMailer möglich), mail_body_plain (bei mail() oder falls html nicht möglich ist), mail_html (html an oder nur plain)

Dateien-Struktur bzgl. Passwort vergessen-Funktion

Aufbauend auf der bisherigen Dateien-Struktur wird es jeweils eine im Ordner opac

• mbr_pwd_forget_form.php und mbr_pwd_forget.php
• mbr_pwd_newset_form.php und mbr_pwd_newset.php im Ordner shared
• staff_pwd_forget_form.php und staff_pwd_forget.php
• staff_pwd_newset_form.php und staff_pwd_newset.php geben.

Gültigkeitsdauer

Was wäre einge angemessene Zeit für die Gültigkeit bzw. Möglichkeit das Passwort zurückzusetzen. Für das Zurücksetzen würde wahrscheinlich eine Zeit von 2 Stunden reichen. Für neue Benutzer, welche ein Passwort anlegen sollen, könnte dies zu kurz und 24 Stunden sinnvoll sein. Was meint Ihr?

Generell Überlegungen und anstehende Entscheidungen bzgl. Ordner- und Datein-Struktur

• Den phpMailer habe ich in dem neuen Ordner "lib" als Unterordner angelegt, da dies m.E. unter class eigentlich nicht richtig aufgehoben ist.

Aufgrund der langsam zunehmenden Funktionalitäten wäre Folgendes zu überlegen und zu entscheiden:

• Unterordner im Ordner "classes" anlegen für bestimmte Themengebiete. Also in diesem Fall Ordner "email". Dort sind dann die beiden Dateien Email.php und EmailSettings.php. Dies habe ich zurzeit so umgesetzt. Die Umsetzung bei den anderen Dateien würde jedoch eine Menge Arbeit bzgl. Änderungen aller Pfade in den jeweiligen Dateien bedeuten.
• Weiter ist zu überlegen, ob der Ordner "classes" als direkter Unterordner von openbiblio bleibt oder ob dieser auf mittelfristiger Sicht in den Ordner "lib" integriert werden soll. Dies würde jedoch eine Menge Arbeit bzgl. Änderungen aller Pfade in den jeweiligen Dateien bedeuten.

So dies sollte mal fürs erste ausreichen.

[LeAchim59]

@375michael40veit Danke für Deine nochmaligen Erläuterungen. Unser Missverständnis basiert wohl darauf, dass Dein Schalter "library-online" heisst, sollte vielleicht besser "member_acoount_online" heißen. Und Du steuerst darüber, ob Anmeldemöglichkeit besteht oder nicht. Denn Dein Szenario 2) Online-Katalog ist eigentlich der bisherige Standardfall. Dass ein Passwort auch bei der Anlage eines Member unbedingt nötig, war Deine Entscheidung. Du hättest es auch dabei belassen können, dass das wie bisher mit "Secret" optional ist. Dann hätte sich halt jemand ohne Passwort einfach nicht anmelden können, wie bisher auch. Aber das und eine spätere Umstellung hast Du ja schon vorgesehen. Die Steuerung der Oberfläche über den Schalter finde ich sogar sehr gut.

[LeAchim59]

@375michael40veit @Larian77 Zu Passwort-vergessen: Ich halte eine Eingabe von Benutzername/nummer UND Email-Adresse für sinnvoll, das sollte dann schon zusammenpassen, so machen das auch kommerzielle Systeme. Nur Emailadresse ist nicht nur aufgrund der mehrfach verwendeten Adressen nicht eindeutig, damit kann ich Emailadressen einfach ausprobieren und so ein Konto übernehmen.

Ich halte für beide Fälle eine Zeit von 2 Stunden für ausreichend. Ggf. wäre das auch wieder ein Parameter, den ein Admin einstellen kann.

Zur Ordnerstruktur: Du schreibst ja richtig, eine Änderung der bisherigen Struktur macht eine Menge Aufwand, den wir vermeiden können. Deshalb würde ich da erst mal nicht unbedingt rangehen. lib für bestimmte Hilfsmodule, die nicht anwendungsspezifisch sind, finde ich gut. classes gehört dann allerdings nicht in lib, eher könnte man innerhalb classes die Klassen noch unterteilen, zB. Admin, Katalog, etc.

[375michael40veit]

@LeAchim59 Vielen Dank für Deine Rückmeldung.

• Bzgl. Dauer werde ich 2 Stunden übernehmen und mal sehen, ob ich es mit unter Bibliothekseinstellung als Parameter mitnehme.
• Ich bin noch etwas hin- und hergerissen bzgl. Benutzername/nummer UND Email-Adresse: -- Richtig ist, dass Mails ausprobiert werden können. Ab 10 Versuche wird eine einfache Bremse eingebaut, um das automatisierte Ausprobieren zu erschweren. -- Auch wenn die E-Mail-Adressen ausprobiert werden könnten, so hat dieser in der Regel keinen Zugriff auf das Mail-Konto hat, zwar eine Mail an die E-Mail-Adresse gesendet wird, jedoch noch kein Passwort neu gesetzt wurde. -- Wenn jemand an dem Link kommt, kann er unabhängig von der Art "und/oder" ein neues Passwort setzen. Allerdings ohne Benutzername ist damit auch kein Login möglich.

Außerdem habe ich gesehen, dass der Link zu Passwort vergessen-Funktion von Dir war. Dafür an Dich nochmals herzlichen Dank.

PhpMailer habe ich in den Ordner lib hinterlegt.

Bzgl. der Ordner-Struktur muss ich mir nochmals Gedanken machen. Zurzeit habe ich den Unterordner classes/email angelegt. Dieser würde dann Kategorie übergreifend Funktionen beinhalten, also bspw. bzgl. mbr (opac) und staff (admin bzw. shared)..

[LeAchim59]

@375michael40veit Stimmt natürlich, was Du über den Empfänger der Email schreibst. Die Schwäche mit dem Link hat ja eigentlich jedes System. Bei der Ordner-Struktur bin ich schmerzfrei, ich könnte auch ohne Unterverzeichnisse leben. Es gibt da ja bisher auch keine dokumentierten Regeln und jeder macht, was er denkt.

[Larian77]

Hi,

sorry, hatte die letzten Monate viel um die Ohren.

danke euch beiden für die Diskussion und an @375michael40veit für die ganzen Umsetzungen.

So wie gedacht gefällt mir das Ganze sehr gut, die offenen Fragen sind glaube geklärt oder war da noch was offen?

Zur Ordnerstruktur gebe ich Recht, dass dies eigentlich einheitlich sein sollte. Ich würde aber auch vorschlagen wir starten für neue Funktionen damit und das Vereinheitlichen können wir dann nochmal in einer späteren Version machen.

Ich komme derzeit auch noch nicht wirklich zum Testen der neuen Funktionen. Kommt ihr hier erstmal selbst dazu?

@375michael40veit ich kenne mich noch nicht wirklich gut mit github aus, wenn alles soweit ist, weißt du wie man das Ganze dann aus deinem Fork wieder ins Hauptprojekt rein bekommt?

[375michael40veit]

@Larian77 Wenn ich die Passwort-Vergessen-Funktion fertig habe, dann werde ich ich einen Pull Request in die Wege leiten oder soll der bisherige Stand schon hinüber geschoben werden? Die Programmierung für die Passwort-Vergrssen-Funktion dafür wird zweite Juni-Hälfte bis Ende Juni andauern. Es fehlt mir noch die Einstellungsseiten für allgemeine E-Miails-Einstellungen, die Einstellungsseite für Nachrichten (z.B. für Pwd vergessen oder Willkommensnachricht) und die Programmierung, dass bei Erstellung eines neuen Nutzers, man entweder ein Passwort vergeben kann oder einen Link versendet, mit der Möglichkeit gleich ein eigenes Kennwort zusetzen.

[375michael40veit]

Info zum aktuellen Stand:

• Die obengenannte Zeit bzgl. der noch ausstehenden Funktionen bis Ende Juni kann ich nicht einhalten. Neues Datum Mitte Juli/zweite Juli-Hälfte, bedingt dass ich zurzeit sowohl beruflich, als auch privat gut gebunden bin.

• Folgendes ist schon umgesetzt, zusätzlich zu dem bereits Veröffentlichten: -- Kennwort-vergessen-Funktion für Members (Beantragung, Neusetzung des Kennwortes) -- Mail-Einstellungen (Auswahl mail() oder PHPMailer -- Einstellungen zur Kennwort-vergessen-Funktion -- Message-Einstellungen. Die DB-Tabelle und die entsprechende Seiten zum Bearbeiten der Nachrichten bieten eine gute Voraussetzung für spätere weitere Nachrichten (z.B. Willkommensmail, Erinnerung bzgl. Rückgabetermine) -- Installationsdateien fürs Anlegen der DB-Tabellen und zum Befüllen

• Zurzeit programmiere ich die Optionswahl zwischen -- keine Passwort-Vergessen-Funktion -- Mail-Adresse oder Benutzernummer oder -- der Funktion Mail-Adresse und Benutzernummer müssen gesetzt werden, um Mail mit entsprechenden Link zum Neusetzen des Kennwortes zugesendet zu bekommen.

• Folgende Funktionen/Programmierungen stehen noch aus: -- Passwort-Vergessen-Funktion für Staff Members. Dies sollte sich zügig umsetzen lassen, da die Grundlagen bereits bestehen. -- Beim Anlegen eines neuen Benutzers und bei Vorhandensein der E-Mail-Adresse auch die Option, dass dem neuen Benutzer gleich beim Anlegen eine Mail mit entsprechendem Link zum Anlegen eines eigenen Kennwortes zugesandt wird. -- Entsprechendes Anlegen der Upgrade-Einstellungen/-Programmierung beim Upgrade auf Version 0.8.1. -- ggf. Einbindung eines Text-Editors zum einfacheren Anlegen von HTML-Messages. @LeAchim59 @Larian77: Habt Ihr bzgl. Text-Editor einbinden bzw. integrieren Erfahrungen bzw Empfehlungen?

[LeAchim59]

@375michael40veit Vielen Dank für Deine bisherige Arbeit. Mach Dir zeitlich keinen Stress, das hier ist ja eher Hobby oder Du nutzt es weil Du etwas lernen möchtest (ich kenne Deine Motivation ja nicht). Leider weiß ich auch keinen Editor, ich kann da auch nur Google bemühen. Prima, dass Du Dir Gedanken um das ganze Thema Email machst, ja, das kann man dann gut für andere Zwecke (Mahnmodul, etc) nutzen.

Wir haben jetzt eine Testinstallation Deines veröffentlichten Eintwicklungsstands gemacht (https://ludo8official.devds.de). Ich kann mich anmelden, Das Feld secret ist nicht mehr da. Ich finde aber nicht:

• Einstellung Datenbank-online
• Eingabe Passwort bei Member
• Funktion zum ändern des Passworts.

viele Grüße Michael

[375michael40veit]

@LeAchim59

• Einstellung Datenbank-online: über Register "Admin" --> Bibliothekseinstellung --> letzte Einstellung namens "Online-Zugriff für Benutzer"

Wenn der Online-Zugriff für Benutzer erlaubt ist:

• Eingabe Passwort bei Member --> Beim Anlegen eines neuen Benutzers kann neben den anderen Daten auch gleich das Kennwort angelegt werden.
• Funktion zum Ändern des Passworts --> Bei bestehenden Benutzern ist bei Ansicht des Benutzerprofils (mbr_view.php) in der Navigation unterhalb von "Bearb. Profil" ein Link namens "Kennw. ändern". --> Die Benutzer selbst können über ihr Profil (mbr_account.php) über die Navigation und dem Link "Kennw. ändern" ihr Kennwort ändern.

[375michael40veit]

Bei folgenden zwei Dateien wurde der Fehler behoben (zu viele Felder), welcher sich nur bei Neuinstallation mit Samples auswirkte: /locale/en/sql/0.8.1/sample/member.sql und /locale/de/sql/0.8.1/sample/member.sql

[LeAchim59]

@375michael40veit Bei mir gibt es das Feld in den Bibliothekseinstellungen nicht. Ich versuche mal rauszufinden, ob der Kollege überhaupt die richtige Version installiert hat. Vielleicht sollte man sich für Testversionen angewöhnen, die Programmversion entsprechend anzupassen.

[375michael40veit]

@LeAchim59 In Deiner Testversion steht Folgendes: Powered by OpenBiblio version 0.8 database version 0.8.1 Es sollte im Footer-Bereich Folgendes stehen: Powered by OpenBiblio version 0.8.1 database version 0.8.1

[375michael40veit]

Info zum aktuellen Stand: (fast geschafft!) Folgendes ist schon umgesetzt, zusätzlich zu dem bereits Veröffentlichten:

• Kennwort-vergessen-Funktion für Members und Staff (Beantragung, Neusetzung des Kennwortes)

• Mail-Einstellungen -- Einstellung zur Kennwort-Vergessen-Funktion: --- "Mail-Adresse oder Benutzernummer" oder "Mail-Adresse und Benutzernummer" müssen gesetzt werden, um Mail mit entsprechenden Link zum Neusetzen des Kennwortes zugesendet zu bekommen. --- Gültigkeitsdauer des "Kennwort-Vergessen"-Codes zum Neusetzen des Kennwortes -- Auswahl mail() oder PHPMailer

• Message-Einstellungen: -- Es sind die jeweiligen Texte angelegt: Passwort-Vegessen-Funktion, Willkommen-Mail. (Der Aufbau kann gut als Grundlage dienen für weitere Funktionen wie Erinnerungsmail für die Abgabe von Medien.) -- Im Text sind die entsprechenden Variablen Vor-, Nachname, Gültigkeitsdauer des Codes und URL gesetzt. -- Die Message-Texte liegen jeweils als HTML-, als auch als PLAIN-Text vor. Im Input-Field für HTML wurde der Editor TinyMCE eingebunden.

• Installationsdateien fürs Anlegen der DB-Tabellen und zum Befüllen

• Upgrade-Dateien für die Aktualisierung auf 0.8.1.

• Beim Anlegen eines neuen Benutzers (member) und bei Vorhandensein der E-Mail-Adresse auch die Option, dass dem neuen Benutzer gleich beim Anlegen eine Willkommen-Mail mit entsprechendem Link zum Anlegen eines eigenen Kennwortes zugesandt wird.

Offen ist noch die Umsetzung beim Anlegen eines neuen Staff-Mitgliedes die Option zu haben, dass Kennwort entweder gleich anzulegen oder per Willkommen-Mail dem neuen Staff-Mitglied das Kennwort selbst erstellen zu lassen. Da die Voraussetzungen nun geschaffen sind, sollte dies nun leicht umsetzbar sein.

[375michael40veit]

Ergänzend: Die meisten Formular bzw. darstellenden Seiten wurden im Inhaltsbereich nicht mehr mit Tabellen erstellt, sondern mit Containern (div) und in diesem Bereich responisiv gestaltet.

Aufgrund der Einbindung des Editors TinyMCE musste auch der Header css-mäßig in Teilen anders aufgebaut werden. Der Header ist in Ansätzen responsiv. Hier wäre ein Hamburger-Menü bei mobilen Endgeräten wie Smartphones wünschenswert.

[Larian77]

Vielen Dank schon mal :-) hatte vieles anderes um die Ohren dass ich hier lange Zeit off war. Sage mir Bescheid, wenn es soweit ist, dass wir das Ganze als neue Version anbinden können.