New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PERSON: Benutzer-Zugang entfernen #2069
Comments
@Michael-Schaer Vielen Dank für deine Beschreibung. Dieser Prozess kann aus meiner Sicht im Core umgesetzt werden. Da wir das ganz deaktivieren oder auch lange Fristen wählen können, sollte das kein Problem sein. Grundsätzlich scheint mir das ein Mehrwert. Weitere Gedanken:
Und noch als Hinweis: Im Zusammenhang mit der ursprünglichen Diskussion scheint auch die neue Permission dank des SWW interessant: #2065 |
Merci für die prompte Rückmeldung!
Ja, das müsste dann halt Wagon-Spezifisch gelöst werden.
Ja, wir müssen wohl die Passwort-Vergessen-Logik noch anpassen. Sicher würde ich aber die Funktion offen lassen, solange der Zugriff nicht gesperrt wurde. Merci für den Hinweis!
Merci für den Hinweis! Nehme ich auf. |
Finde die Überlegung sinnvoll und nehme das Thema gerne bei uns in der Fachgruppe auf. Inaktive User zu "schützen" halte ich für sinnvoll.
Normalerweise gibt es keinen Hinweis zu einem Login-Versuch. Auch die Passwort-Vergessen-Logik gibt nicht preis, ob es den Account auch wirklich gibt. So wird verhindert, dass jemand alle möglichen E-Mail-Adressen durchprobiert. |
Guter Input! Ich habe die Anforderung angepasst, so dass ein Mail verschickt wird, anstelle einer Meldung im UI. |
Ich habe eine Anforderung gelöscht, die gar nicht nötig ist. Siehe #2148 |
Wie sieht es mit Accounts ohne aktives Login aus? |
Ich verstehe deinen Punkt! Wenn nur eine Haupt-E-Mail eingetragen ist, aber das Login gar nie verschickt wurde, ist die Angriffsfläche vielleicht etwas kleiner: Es wurde kein Einladungs-Mail verschickt und es gibt keine Login-Aktivität, die man abgreifen könnte. Daher fände ich es als ersten Schritt auch in Ordnung, diesen Fall zu ignorieren. Vielleicht hat aber Puzzle hier noch einen Tipp? |
Dinge die mir beim Durchlesen fürs Refinement aufgefallen sind:
|
Das würde zum nächsten Punkt passen: Das Login wird nicht verhindert, danach aber nichts mehr angezeigt. So könnte man das lösen.
Stimmt. Wenn das einfacher ist als das E-Mail, ist das für mich auch eine Möglichkeit.
Ich würde vor dem Versenden des Login-Mails keine automatische Sperrung einrichten. Einfach der Kompatibilität mit dem Core und der Einfachheit zu Liebe.
Diese würde ich gleich behandeln, wie diejenigen, die noch kein Login-Mail erhalten haben. |
Offene Punkte:
|
Bisher ist der Zugriff auf ein Hitobito-System zeitlich unbeschränkt. Das ist aus Security- und Datenschutz-Sicht nicht optimal und sollte angepasst werden.
Daraus ergibt sich folgende Überlegung:
Automatismus
Funktion "Login schicken"
Funktion "Login sperren"
Erscheint im Drop-Down unter "Login schicken"Login-Icons
Sperrung soll im Icon miteinbezogen werden:
hitobito/app/models/person.rb
Line 366 in bee9e3a
Login UI
Wenn sich eine gesperrte Person einloggt, erhält sie ein E-Mail (konfigurierbar in den Texten):
Im Moment gibt es die Möglichkeit, herauszufinden, ob es eine E-Mail-Adresse in der MiData gibt oder nicht, wenn die Passwort-Reset-Funktion verwendet wird. Dieser Umstand sollte wenn möglich auch geändert werden.
Siehe auch die ursprüngliche Idee, die kontrovers aufgenommen wurde: #1297
Tech-Spec
ToDo
inactivity_block_warning_sent_at
undblocked_at
aufPerson
, beide datetime, defaultnil
InactivityBlockWarningJob
, der täglich läuftlast_sign_in_at
älter als X Monate istnil
und in diesem Fall keine Personen sucheninactivity_block_warning_sent_at
aufDateTime.now
custom_content_mail
in einem Mailer versendet werden (dafür auch einen eigenen Mailer anlegen).InactivityBlockJob
, der täglich läuftinactivity_block_warning_sent_at
älter als Y Monate ist UND derenblocked_at
leer istnil
und in diesem Fall keine Personen suchenblocked_at
aufDateTime.now
email_compromised_situation
undsuspend_person_situation
je einen Button "Zugang blockieren" einbauenblock
im SecurityToolsController aufcurrent_person
nochorigin_user
sein)blocked_at
der Person aufDateTime.now
und zeigt Flash-Nachrichtblocked_at
ist nichtnil
):nil
sind auch erklären dass das nach X + Y Monaten ohne Login automatisch passiert, und mit Button um die Person zu entsperren.unblock
im SecurityToolsController aufblocked_at
undinactivity_block_warning_sent_at
aufnil
und zeigt Flash-Nachrichttemplate.can?(:update, @user)
@user.blocked_at.present?
unblock
im SecurityToolsController aufbefore_action
imApplicationController
anlegencurrent_person.blocked_at.present?
, und wenn ja, eine spezielle minimalistische View rendern (einrender
in diesem Hook müsste den Rest der Action abbrechen, falls nicht müsste es mit einemredirect
gehen)before_action
Hook des ApplicationControllers zu realisieren, könnte man stattdessen eine eigene Rack Middleware schreiben. Aber dann müsste man sich möglicherweise ActiveRecord und Devise selber einrichten oder zumindest requiren...last_sign_in_at
bereits jetzt älter als X + Y Monate ist, und bei diesen Personenblock_warning_sent_at
auf heute vor Y Monaten setzen (an diese Personen wollen wir keine Warnung mehr schicken)The text was updated successfully, but these errors were encountered: