Ich muss ein Protokoll schreiben, wenn jemand nicht in meiner App angemeldet ist (um Bruteforce-Versuche zu verfolgen). Auch ich habe mich dafür entschieden, erfolgreiche Authentifizierungen zu protokollieren. Also habe ich einen SessionsController & lt; Devise :: SessionsController und versuchte die Sessions # create-Methode wie folgt zu überschreiben: Ссылка
Der erste Teil funktioniert perfekt, aber wenn die Auth Failes Schienen wirft eine Art von Ausnahme und erreicht nie die if-Anweisung. Also ich weiß nicht was ich machen soll.
Diese Antwort auf eine vorherige SO-Frage - Devise: Anmeldeversuche anmelden hat die Antwort.
Die create-Aktion im Devise-Controller ruft warden.authenticate! auf und versucht, den Benutzer mit den angegebenen Parametern zu authentifizieren. Wenn die Authentifizierung fehlschlägt, authentifizieren Sie sich! ruft die Gerätefehler-App auf, die dann die Aktion "SessionsController # new" ausführt. Beachten Sie, dass alle Filter für die Erstellungsaktion nicht ausgeführt werden, wenn die Authentifizierung fehlschlägt.
Die Lösung besteht also darin, nach der neuen Aktion einen Filter hinzuzufügen, der den Inhalt von env ["warden.options"] überprüft und die entsprechende Aktion ausführt.
Ich habe den Vorschlag ausprobiert und war in der Lage, sowohl den erfolgreichen & amp; fehlgeschlagene Anmeldeversuche Hier ist der relevante Controller-Code:
%Vor%Das Protokoll enthält die folgenden Einträge:
Prakashs Antwort ist hilfreich, aber es ist nicht ideal, sich auf SessionsController#new als Nebeneffekt zu verlassen. Ich glaube, das ist sauberer:
Sehen Sie sich Graemes Antwort an, wenn Sie lieber Wardens Callbacks verwenden möchten (Devise wird mit Warden implementiert).
Ich hatte die gleiche Frage, konnte sie aber nicht mit "warden.options" lösen, da diese in meinem Fall vor der Weiterleitung zur Aktion sessions#new gelöscht wurden. Nachdem ich einige Alternativen untersucht hatte, die ich für zu spröde hielt (weil sie dazu führten, dass einige Devise-Klassen erweitert und bestehende Methoden mit Aliasing versehen wurden), verwendete ich einige Callbacks von Warden . Es funktioniert besser für mich, da der Rückruf innerhalb des aktuellen Anfrage-Antwort-Zyklus aufgerufen wird und die Parameter alle im Objekt env beibehalten werden.
Diese Rückrufe werden benannt und scheinen so zu sein, dass sie diese und ähnliche Probleme lösen. Und sie sind dokumentiert!
Warden unterstützt die folgenden Rückrufe ab warden-1.2.3 :
after_set_user after_authentication (nützlich für die Anmeldung erfolgreicher Anmeldungen) after_fetch (Alias für after_set_user ) before_failure (nützlich für die Protokollierung fehlgeschlagener Anmeldungen - Beispiel unten) after_failed_fetch before_logout on_request Jeder Callback wird direkt auf die Klasse Warden::Manager gesetzt. Um einen fehlgeschlagenen Authentifizierungsversuch zu verfolgen, fügte ich Folgendes hinzu:
Ich erwarte, dass Sie den before_logout -Rückruf auch verwenden können, um Abmeldeaktionen zu verfolgen, aber ich habe es nicht getestet. Es scheint auch prepend_ Varianten der Callbacks zu geben.
Tags und Links authentication devise ruby-on-rails-3.2