flask-login Ich habe eine Anmeldefunktion mit flask-login implementiert, wollte aber den internen Mechanismus kennen, also habe ich den Mechanismus anhand der Dokumentation und des Quellcodes untersucht!
Sie können die UserMixin-Klasse erweitern.
from flask_login import LoginManager
login_manager = LoginManager()
login_manager.init_app(app)
login_manager.login_view = "login"
@login_manager.user_loader
def load_user(userid):
return User(userid)
Das hier von load_user empfangene Argument ist der von get_id () zurückgegebene Wert, der in der User-Klasse definiert ist. Lassen Sie get_id () bei Bedarf den Wert zurückgeben, der erforderlich ist, um den Benutzer aus der Datenbank abzurufen: smile:
def login():
form = LoginForm()
if form.validate_on_submit():
login_user(user)
flask.flash('Logged in successfully.')
next = flask.request.args.get('next')
if not is_safe_url(next):
return flask.abort(400)
return flask.redirect(next or flask.url_for('index'))
return flask.render_template('login.html', form=form)
Übergeben Sie den Benutzer an login_user und flask-login erledigt den Rest. Es speichert hauptsächlich die Informationen, die zum Aufrechterhalten des Anmeldestatus in der Sitzung erforderlich sind, aktualisiert den Benutzer des Anforderungskontexts, sendet das Anmeldesignal usw .: bow:
@app.route("/logout")
@login_required
def logout():
logout_user()
return redirect(somewhere)
Es ist sehr einfach, rufen Sie einfach logout_user auf. In der Funktion logout_user wird der angemeldete Benutzer abgerufen und der Abmeldevorgang ausgeführt, sodass der Benutzer nicht übergeben werden muss. Grob gesagt ist es das Gegenteil von Anmelden. Um den Anmeldestatus beizubehalten, löschen Sie den in der Sitzung enthaltenen Wert, aktualisieren Sie den Benutzer im Anforderungskontext auf anonym_user und senden Sie das Abmeldesignal. : Augen rollen:
Rufen Sie im Dekorator login_required den aktuellen Benutzer ab. current_user versucht, den Benutzer aus den in der Sitzung gespeicherten Informationen abzurufen (insbesondere user_id). [ein] Da es vor der Anmeldung ist, hat die Sitzung keine Benutzer-ID, sodass das Abrufen des Benutzers fehlschlägt. Wenn request_loader definiert ist, verwenden Sie diese, um sich anzumelden. Da request_loader diesmal nicht definiert ist, ist current_user ein anonymer Benutzer. Da is_authenticated, das in der Klasse Anonymous User definiert ist, False zurückgibt, wird festgestellt, dass es nicht authentifiziert ist, und LoginMangers unauthorized () wird aufgerufen, um zum Anmeldebildschirm umzuleiten.
Dies entspricht [a] des Verhaltens vor der Anmeldung. Wenn der Benutzer erfolgreich erfasst wurde, wird der Benutzer so zurückgegeben, wie er ist. Überprüfen Sie, ob der Benutzer mit is_authenticated authentifiziert ist. Da es sich nicht um einen anonymen Benutzer handelt, wird True zurückgegeben, wie im Benutzermodell definiert. Da festgestellt wird, dass es authentifiziert ist, wird die nachfolgende Verarbeitung fortgesetzt: Lachen:
--HttpOnly-Attribut Standardmäßig enthält Flask Sitzungsinformationen auf der Clientseite, die als Cookie-basierte Sitzung bezeichnet werden. Setzen Sie daher SESSION_COOKIE_HTTPONLY auf True, um zu verhindern, dass Javascript auf diese Informationen zugreift. (Standard ist True) [1]
Begrenzte Cookie-basierte Übertragung von Sitzungscookies nur an HTTP Setzen wir SESSION_COOKIE_SECURE auf True. (Standard ist False) [2]
Sitzungsschutz Da die Flask-Anmeldung einen Hash-Wert aus der IP-Adresse und dem Benutzeragenten generiert und in der Sitzung hält, wird der Anmeldestatus durch das Standardverhalten im Grundmodus verworfen, wenn sich dieser Wert gegenüber dem vorherigen Zeitpunkt ändert. Auf der Kolbenseite wird der Anmeldestatus beibehalten, wenn die Einstellung für die Sitzungspersistenz festgelegt ist. Diese Sitzung wird jedoch als nicht aktuell gekennzeichnet. Im starken Modus wird der Anmeldestatus verworfen, wenn sich der Hash geändert hat.
By default, it is activated in "basic" mode. It can be disabled in the app’s configuration by setting the SESSION_PROTECTION setting to None, "basic", or "strong". When session protection is active, each request, it generates an identifier for the user’s computer (basically, a secure hash of the IP address and user agent). If the session does not have an associated identifier, the one generated will be stored. If it has an identifier, and it matches the one generated, then the request is OK. If the identifiers do not match in basic mode, or when the session is permanent, then the session will simply be marked as non-fresh, and anything requiring a fresh login will force the user to re-authenticate. (Of course, you must be already using fresh logins where appropriate for this to have an effect.) If the identifiers do not match in strong mode for a non-permanent session, then the entire session (as well as the remember token if it exists) is deleted. [3]
[1] https://flask.palletsprojects.com/en/1.1.x/config/#SESSION_COOKIE_HTTPONLY [2] https://flask.palletsprojects.com/en/1.1.x/config/#SESSION_COOKIE_SECURE [2] https://flask-login.readthedocs.io/en/latest/#session-protection
Recommended Posts