Ich habe die letzten Tage auf den (mysql) Triggern gelesen ... ich versuche gerade, eine gute Methode zum Aktualisieren der Informationen eines Benutzers herauszufinden.
Der Fall, der dafür verwendet wird, bezieht sich auf ein Benutzerverwaltungssystem:
Nehmen wir zum Beispiel einen admin Benutzer, der einen regular Benutzer zu einem manager aktualisiert, dann würde dieser Benutzer type change dann enable|disable Software-Features auf der Benutzeroberfläche haben.
Problem:
Sie werden nichts über diesen Benutzer type change wissen, wenn Sie die Datenbank nicht abfragen und zum Beispiel die Variable $_SESSION['user']['type'] zurücksetzen und / oder der Benutzer sich vom System abmeldet.
Frage: Gibt es irgendwelche guten Methoden, um diese Kopfschmerzen zu lösen?
Ich denke nicht, dass mysql Auslöser hierfür ideal sein würden . Warum? Weil Sie höchstwahrscheinlich mit einem Teil der Logik in PHP und einem Teil in MySQL enden werden. Es ist eine gute Sache, bei einer Technologie zu bleiben, weil es für Sie und Ihre Kollegen später einfacher ist, den Code zu warten / zu debuggen.
Wenn in Ihrem Fall die Änderung der Benutzerrolle sofortige Maßnahmen erfordert, müssten Sie entweder die Benutzerrolle bei jedem Skriptlauf laden oder den Benutzer mit einem Flag in der Datenbank abmelden, das signalisiert, dass seine Sitzung nicht ausgeführt wird gültig (oder Sie könnten Ihre eigene session_set_save_handler ) implementieren, die die Sitzung speichern würde irgendwo in der Datei, wo Sie es löschen können, um den Benutzer auszuloggen).
Es hängt von Ihren Bedürfnissen ab, welche Lösung besser zu Ihrem Fall passt.
Es hängt also wirklich von Ihren Bedürfnissen ab, ob es besser ist, den Benutzer auszuloggen, ihm sofort neue Berechtigungen zu geben oder bis zur nächsten Anmeldung zu warten.
Frage: Gibt es irgendwelche guten Methoden, um diese Kopfschmerzen zu lösen?
Finden Sie gute Gründe, es nicht zu tun!
Das hört sich vielleicht wie ein Witz an, aber ich meine es ernst. Sie müssen Folgendes beachten:
Wer diese Fragen nicht beantworten kann, braucht diese Funktion nicht wirklich.
Finde einfache Alternativen:
Das ist keine Faulheit. Konzentriere dich nur auf den wahren Wert.
Eine Alternative wäre das Ausführen von ajax-Anfragen mit einem gewissen Zeitintervall, die Ihren Benutzer $ _SESSION aktualisieren.
Wenn Sie Änderungen an Ihrem 'type' vornehmen, können Sie tun, was Sie wollen, z. B. erzwingen, dass der Benutzer Ihre Anwendung erneut anmeldet, oder nichts anderes tun, als $ _SESSION-Informationen zu aktualisieren.
Natürlich müssen Sie wissen, ob Sie diese Informationen wirklich benötigen, bevor der Benutzer sich beim nächsten Mal abmeldet und anmeldet, mit einem aktualisierten Profil.
Ich denke, das Speichern Ihrer Sitzung in Caching-Mechanismen wie Redis würde Ihnen einen zusätzlichen Vorteil verschaffen. Es ist leichter als das Speichern von Sitzungsdaten in der Datenbank. Sie können Cluster sehr einfach erstellen. Klicken Sie auf hier um die Beispielimplementierung zu sehen.
Sobald sich ein Benutzer "type" ändert, können Sie den redis-Datencache laden und nach Ihren Wünschen aktualisieren.
Ich denke, der sicherste Weg, dies zu tun, und der, den ich wählen würde, ist der "Kopfschmerz" Weg.
Alternative, die abhängig von Ihrer Anwendung etwas teuer sein kann:
Jedes Mal, wenn ein Benutzer ein Sitzungstoken vorlegt, überprüfen Sie anhand der Datenbank die Gültigkeit der Sitzung. Wenn diese Sitzung ungültige Informationen enthält (dh der 'Typ' stimmt nicht mehr überein), erzwingen Sie, dass sich der Benutzer erneut anmeldet.
Eine weitere Alternative hinzufügen:
Verwenden Sie keinen MYSQL-Trigger, wenn der Anwendungsaufrufer (der Administrator) den "Typ" von Benutzer A aktualisiert, er ruft auch an, wo Sie die Sitzungen zwischenspeichern, und entweder (a) aktualisiert die Sitzung (nicht empfehlenswert) ) oder (b) macht die Sitzung ungültig und zwingt den Benutzer, sich erneut anzumelden.
* Beachten Sie, dass alle diese Lösungen erfordern, dass der Benutzer seine Anmeldeinformationen erneut eingibt, nachdem er die "Manager" -Macht neu gefunden hat, bevor er Zugriff auf das "Manager-Zeug" hat. Ich denke, das ist sicherer, als die Sitzung ohne Authentifizierung zu aktualisieren.
Meine empfohlene Methode wäre, die type jedes Benutzers in der Datenbank zu speichern. Die Probleme, die auftreten würden, wenn Sie sich entscheiden würden, type als Sitzungsvariable zu speichern, wäre (unter anderem):
Nach Ablauf der Sitzung gehen diese Informationen verloren. Normalerweise dauern die Sitzungen 30 Minuten, obwohl Sie dies so lange ändern können, wie Sie möchten. Wenn Sie jedoch eine Sitzung erstellen, die einen Monat lang dauert, wird jeder, der Zugriff auf diesen Benutzercomputer hat, im Benutzerkonto angemeldet, ohne dass ein Kennwort verwendet werden muss.
Sie könnten keine leistungsfähigen Abfragen verwenden, die von Datenbanken angeboten werden (wie zB MySQL, das SQL verwendet). Wenn Sie Ihre Informationen in Sitzungen speichern, können Sie sicher sein, dass Sie jede Benutzerinformation 1 für 1 nachschlagen können, aber warum sollten Sie das Rad neu erfinden? Es ist nicht einfach, eine Datenbankstruktur von Grund auf neu zu entwickeln, ich würde es daher nicht empfehlen.
Was Ihre Bedenken bezüglich des Zugriffs auf eine Datenbank anbelangt, nachdem die Informationen aktualisiert wurden, würde ich nicht sagen, dass diese Informationen so bedenklich sind, wie Sie es für möglich halten. Stellen wir uns die folgenden Beispiele vor:
1)
Wenn ein Benutzer zum Beispiel momentan Manager ist und eine Website lädt, auf der er mächtige Aktionen ausführen kann, wird er gleich danach als normaler Benutzer degradiert Diese Information in der Datenbank zu haben würde perfekt funktionieren. Wenn der Benutzer versucht, seine Kräfte zu nutzen (die nicht mehr seine sind), würde er auf eine Schaltfläche klicken, die eine Anfrage an die Datenbank senden würde, um seine type zu bestätigen. Datenbankabfragen sind sehr schnell, Geschwindigkeit ist also kein Problem. Ich wäre mehr besorgt über die Geschwindigkeit, die Sie benötigen, um Informationen von einer Sitzungsvariablen als von der Datenbank zu erhalten.
2)
Wenn sich der Benutzer auf einer Seite befand, während er ein normaler Benutzer war, und während er auf der Seite war, wurde er Manager , dann konnte er seine Befugnisse ausüben nach dem Aktualisieren der Seite. Ich meine, wenn Sie Sitzungen verwendet haben und die Seite die Informationen automatisch mit etwas wie AJAX abrufen und dann seine Optionen auf der Seite aktualisieren sollte, würde das viel mehr Serverleistung verbrauchen als eine einfache Aktualisierung.
Um ein einfaches SELECT * FROM myTable WHERE id = 4 zu erhalten, kann es nur 1 Millisekunde dauern, bis es in einer Datenbank ausgeführt wird. Datenbanken wurden speziell auf ihre Geschwindigkeit ausgelegt, weshalb sie bevorzugt werden.
JEDOCH , vielleicht haben Sie keinen Zugriff auf eine Datenbank und suchen deshalb nach einer Alternative? Nun, du hast Glück! MySQLi ist eine Datenbank, die nur eine Datei zum Speichern der Informationen verwendet. Es wurde speziell für Benutzer entwickelt, die wenig Ressourcen haben und viele der Fähigkeiten haben, die MySQL hätte.
Da jeder Benutzer ein role oder type hat, bedeutet dies, dass die Fähigkeit, Inhalte in Ihrer Anwendung anzuzeigen oder zu bearbeiten, mit diesem Faktor fest verbunden ist. Dies bedeutet, dass die 2 grundlegenden Dinge, die Ihre Sitzungsvariablen haben sollten, userID und userType sind, die Sie auch in Ihrer Datenbank speichern sollten
Diese Informationen können beispielsweise als kleines Array an $_SESSION['user'] übergeben werden, wobei Ihr Array-Schlüssel der userID und der userType der Wert sein kann.
Sobald Sie sich angemeldet haben, werden Ihre anfänglichen Werte in session gespeichert. Damit Ihre Anwendung weiß was userA in Ihrer Anwendung anzeigen oder bearbeiten kann, führen Sie in Ihrem Skript im Grunde einen Vergleich mit dem userType durch, das userA hat. Aber um zu erreichen, was Sie wollen, müssen Sie die Information am Anfang jedes VIEW/PAGE Ihrer Anwendung im Grunde wieder holen. Wenn% userType userA zugewiesen wurde, zeigen Sie einfach eine Nachricht an, dass er / sie sich automatisch in 15 Sekunden abmeldet (geben Sie ihm Zeit, die Nachricht selbst zu lesen), damit die Änderungen wirksam werden. Während Ihr Benutzer diese Nachricht sieht, nehmen Sie die aktuellen Sitzungsdaten, die er / sie hat, in der Datenbank auf, da einige Sitzungsvariablen bei einem Upgrade oder Downgrade von userType verfügbar sind (oder nicht). Indem Sie den Vergleich der userType am Anfang jeder VIEW/PAGE Ihrer Anwendung platzieren, ersparen Sie sich die Kopfschmerzen, dass ein Benutzer Daten verlieren kann.
Wenn Ihre Skripte $_SESSION['user']['type'] verwenden, um über die Benutzerprivilegien zu erfahren, würde ich einfach ihren Wert ändern.
Oder habe ich das Problem nicht verstanden?
Tags und Links triggers php mysql session session-variables