6 Stimmen

Symfony2 FOSUserBundle - Gegen das Flag "Benutzer aktiv" bei der Anmeldung validieren

Ich habe eine Flagge auf meinen Benutzern für 'aktiv' und wenn sie auf null oder null gesetzt ist, lasse ich den Login nicht zu.

Ich habe ein paar Ansätze ausprobiert und bin kurz gekommen.

Wenn ich den Logout-Route mache, wird die Flash-Nachricht nicht beibehalten, sodass der Benutzer nichts sieht.

Ich habe versucht, eine Validierung im Anmeldeformular hinzuzufügen, damit ein normaler Formfehler ausgelöst wird, wenn die Flagge nicht auf true gesetzt ist, aber in diesem Ordner (vendor / Bundles / FOS / UserBundle / Form / Type) finde ich nichts für das Anmeldeformular, nur Registrierung und dergleichen, also wüsste ich nicht, wo ich es platzieren soll oder von wo aus ich erben sollte, um es zu überschreiben.

Ich habe auch versucht, wie hier vorgeschlagen, manuell auszuloggen, aber das hat mich mit einem weißen Bildschirm des Todes zurückgelassen...

Irgendwelche Vorschläge, wie man dies einfach erreichen kann?

** * ** * ** * ** * ** AKTUALISIERUNG ** * ** * ** * *

Mir wurde klar, dass ich wahrscheinlich vorgehe, indem ich einen Validator im Anmeldeformular hinzufüge. Ich habe es derzeit in den Controller der ersten Route codiert, zu der ein Benutzer gesendet wird, aber das bietet nicht viel Sicherheit, wenn ein Benutzer eine Route tippt, bevor er sich anmeldet, weil bei einem erfolgreichen Login-Versuch meine Standard-"Landing-Page" nach dem Login nicht die Route ist, zu der der Benutzer gelangt, sondern er landet auf der von ihm gewählten Route...

*** AKTUALISIERUNG ERNEUT ** * *

Die Dienstkonfigurationsdatei hat dies...

Und dieser Parameter ist hier definiert...

    Symfony\Component\Security\Core\User\UserChecker

Um die Anmelde-Logik zu ändern, muss ich

Symfony\Component\Security\Core\User\UserChecker

Jetzt habe ich das getan, indem ich diesen Parameter oben in meiner eigenen parameters.ini in der Symfony app / config wie folgt überschrieben habe

security.user_checker.class  = BizTV\UserBundle\Controller\UserChecker

.. und habe diese Überprüfung zu meinem Benutzerprüfer hinzugefügt...

    //Test für companylock...
    if ( !$user->getCompany()->getActive() ) {
        throw new LockedException('Das Unternehmen dieses Benutzers ist gesperrt.', $user);
    }

Hier ist die gesamte Datei:

 *
 * For the full copyright and license information, please view the LICENSE
 * file that was distributed with this source code.
 */

//Überschreiben von Mattias

namespace BizTV\UserBundle\Controller;
//namespace Symfony\Component\Security\Core\User;

use Symfony\Component\Security\Core\Exception\CredentialsExpiredException;
use Symfony\Component\Security\Core\Exception\LockedException;
use Symfony\Component\Security\Core\Exception\DisabledException;
use Symfony\Component\Security\Core\Exception\AccountExpiredException;

use Symfony\Component\Security\Core\User\UserInterface;
use Symfony\Component\Security\Core\User\UserChecker as OriginalUserChecker;

/**
 * UserChecker überprüft die Benutzerkontoflaggen.
 *
 * @author Fabien Potencier 
 */
class UserChecker extends OriginalUserChecker
{
    /**
     * {@inheritdoc}
     */
    public function checkPreAuth(UserInterface $user)
    {

    //Test für companylock...
    if ( !$user->getCompany()->getActive() ) {
        throw new LockedException('Das Unternehmen dieses Benutzers ist gesperrt.', $user);
    }

        if (!$user instanceof AdvancedUserInterface) {
            return;
        }

        if (!$user->isCredentialsNonExpired()) {
            throw new CredentialsExpiredException('Die Benutzeranmeldeinformationen sind abgelaufen.', $user);
        }

    }

    /**
     * {@inheritdoc}
     */
    public function checkPostAuth(UserInterface $user)
    {

    //Test für companylock...
    if ( !$user->getCompany()->getActive() ) {
        throw new LockedException('Das Unternehmen dieses Benutzers ist gesperrt.', $user);
    }  

        if (!$user instanceof AdvancedUserInterface) {
            return;
        }

        if (!$user->isAccountNonLocked()) {
            throw new LockedException('Das Benutzerkonto ist gesperrt.', $user);
        }

        if (!$user->isEnabled()) {
            throw new DisabledException('Das Benutzerkonto ist deaktiviert.', $user);
        }

        if (!$user->isAccountNonExpired()) {
            throw new AccountExpiredException('Das Benutzerkonto ist abgelaufen.', $user);
        }
    }
}

* Update nb 3 * ** * **** Jetzt muss ich nur noch überprüfen, ob es tatsächlich auf die Standardbenutzersperre prüft, was überraschenderweise nicht von Haus aus erfolgt. (Danke nifr, dass du mich so weit gebracht hast!)

**Meine Benutzerentität beginnt so, und wie Nifr sagte, muss ich das AdvancedUserInterface implementieren, aber dies ist wahrscheinlich nicht der richtige Weg, da es immer noch nicht nach dieser Sperre überprüft... aber es wirft mir auch keine Fehlermeldung (wenn ich sie ändere und das umstelle und Analogie implementiere AdvancedUserInterface und dann EXTENDS Basisbenutzer wirft es einen Fehler, also...)

`Nicht sicher, ob das der richtige Weg ist, wenn Sie sowohl den Basiskunden erweitern als auch AdvancedUserInterface implementieren möchten. Wenn Sie es wie oben gemacht haben, kann ich die Funktionen, die es hinzufügen soll, immer noch nicht verwenden (aber es wirft mir auch keine Fehlermeldung), aber wenn ich die EXTENDS und IMPLEMENTS so ändere (Zeile 18)...

Klasse Benutzer implementiert AdvancedUserInterface erweitert Basiskunde 

...bekomme ich diesen Fehler:

Parse error: Syntaxfehler, unerwartetes T_EXTENDS, erwartet ' {' in /var/www/cloudsign/src/BizTV/UserBundle/Entity/User.php in Zeile 18`**

6voto

Nicolai Fröhlich Punkte 49234

FOSUserBundle / Symfony hat bereits eine Art "aktiv" Flag integriert.

FOS\UserBundle\Model\User stellt bereits die Eigenschaften "locked" und "enabled" zur Verfügung, die im Grunde für diesen Zweck gedacht sind. Der Unterschied zwischen diesen beiden Eigenschaften ist wie folgt (Zitat von @stof's Kommentar hier)

Vom Standpunkt des Sicherheitskomponente aus gibt es keinen wirklichen Unterschied: beide sind am Einloggen gehindert. Der Unterschied ist semantischer Natur: deaktivierte Benutzer sind allgemein Benutzer, die ihr Konto aktivieren müssen (zum Beispiel, wenn Sie die Bestätigung der E-Mail in FOSUserBundle aktivieren, ist der Benutzer bei Erstellung deaktiviert und bei Bestätigung aktiviert). Andererseits ist das Sperren eines Benutzers im Allgemeinen eine Handlung des Administrators der Website, um einen Benutzer zu sperren. Es macht keinen Sinn, das gleiche Feld in der Datenbank zu verwenden, da dies gesperrten Benutzern ermöglichen würde, erneut Zugriff zu erhalten, indem sie einfach den Bestätigungsprozess durchlaufen.

Die Überprüfung von gesperrten/deaktivierten Benutzern wird von einem UserChecker (Symfony stellt diesen als @security.user_checker bereit) in FOSUserBundle's AuthenticationListener durchgeführt, der Symfony\Component\Security\Core\User\UserCheckerInterface implementiert.

Um inaktive Benutzer zu einer anderen Route umzuleiten, würden Sie folgendes tun:

  1. Fangen Sie die Symfony\Component\Security\Core\Exception\DisabledException im try/catch-Block in einem erweiterten AuthenticationListener ab
  2. Leiten Sie den Benutzer zu einer bestimmten Route um, wenn die gefangene Ausnahme vom Typ InactiveUserException ist

Verschieben Sie optional die Umleitung zu einem neu erstellten EventListener/-Subscriber, der im erweiterten AuthenticationListener ausgelöst wird. Auf diese Weise könnten Sie später zusätzliche Listener erstellen, z.B. für Logging-Zwecke, und sie einfach dem Ereignis des Einloggenversuchs eines inaktiven Benutzers zuordnen.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X