it-swarm.com.de

Erhöhen Sie das Sitzungszeitlimit

Ich habe also die Anforderung, dass ich kurz davor stehe, wie man in Drupal 8) fertig wird.

Ich werde versuchen, die Anforderungen zu vereinfachen. Ich habe zwei Rollen. Sie schließen sich im Wesentlichen gegenseitig aus. Nennen wir sie "Intern" und "Client".

Die Anfrage besteht darin, Clients auf unbestimmte Zeit anzumelden ... nennen wir es Jahre . Interne Benutzer müssen für einen kurzen Zeitraum, z. B. 1 Tag, oder nur für die Sitzung angemeldet sein. ( Hinweis: Ich habe diese Anforderungen nicht gestellt, sondern nur codiert ... haha ​​)

Mein Verständnis des Drupal Login ist, dass es wirklich zwei Dinge gibt, die dies steuern ... es gibt die Cookie-Lebensdauer eines Benutzers und die Sitzungslebensdauer (auf dem Server). Wenn ich das einstelle Cookie-Lebensdauer bis 1 Woche, aber die Sitzungslebensdauer beträgt 1 Tag. Der Benutzer wird im Wesentlichen nach 1 Tag abgemeldet. B/C Ihr Cookie stimmt mit einer Sitzung überein, die nach einem Tag nicht mehr existiert. Stimmt das?

Ich denke, ich muss mit der Obergrenze beginnen. Wenn ich möchte, dass mein Benutzer 1 Jahr lang angemeldet ist, muss meine Serversitzung 1 Jahr dauern. Eine meiner Fragen lautet: Was sind die Risiken/Nachteile/usw. beim Festlegen meiner Serversitzung auf 1 Jahr? Angenommen, mein Server erhält 50.000 Besuche pro Monat. Was ist, wenn es nicht 1 Jahr ist und ich es mit 2 Jahren will? Ich kann anscheinend keinen endgültigen Leitfaden für die Obergrenze der Serversitzung finden. Es scheint, dass es viele Faktoren gibt, die diese Sitzung ebenfalls klären könnten ...

Ok, das Obige ist also eine Frage ... vorausgesetzt, ich kann die Serversitzung festlegen, wie kann ich den Besuch der Cookie-Lebensdauer basierend auf der Benutzerrolle durchführen lassen? Ich komme an einen Punkt, an dem es anscheinend nicht möglich ist, diese Einstellung zu ändern, und ich muss möglicherweise eine Art Routenabonnenten und benutzerdefinierte Cookies erstellen und nicht, um die internen Benutzer zu erkennen und sie abzumelden, wenn ich siehe, sie sind zu lange eingeloggt ...

Jede Hilfe wäre sehr dankbar ...

5
Dave

Ich habe dieses Ziel in der Vergangenheit für Drupal 7 mit etwas benutzerdefiniertem Code erreicht.

  1. Stellen Sie die Lebensdauer der Cookies und das Zeitlimit für die Serversitzung auf die größere der beiden Zahlen ein. In Ihrem Fall sind das wahrscheinlich 2 Jahre.
  2. Schreiben Sie ein benutzerdefiniertes Skript (z. B. in drush), das veraltete Sitzungen findet und löscht.

Für Artikel 2 bedeutet dies für Sie, dass die internen Benutzer mit einer kurzen Lebensdauer gefunden und ihre Sitzung gelöscht werden müssen, wenn sessions.timestamp Ein Limit überschreitet. Laut system.install Enthält diese Spalte The Unix timestamp when this session last requested a page.

Das Limit Ihrer Sitzungstabelle hängt von der Datenbankserverhardware ab. Meine Erfahrung auf einer ziemlich großen Site zeigt jedoch, dass Sie Millionen von Sitzungsdatensätzen haben können und dies kein großes Leistungsproblem darstellt. Ich fand jedoch auch heraus, dass die Benutzerinteraktion einer Leistungskurve folgte. 90% der Benutzer, die sich verpflichtet und verlobt haben, haben dies innerhalb des ersten Tages getan. 95% waren innerhalb der ersten Woche und nach 3 Monaten waren es 98%. Das Speichern der Cookie-Daten darüber hinaus für einen Rundungsfehler ist im Allgemeinen nicht besonders nützlich.

Ich habe festgestellt, dass der Versuch, eine SQL-Löschung direkt durchzuführen, nicht gut skaliert. Stattdessen habe ich eine Schleife geschrieben, die Datensätze zum Löschen findet und dann einzelne Löschabfragen mit der Bedingung WHERE sid = :sid Ausführt, sodass ein Primärschlüssel verwendet wird. Dies hatte die größte Leistung bei minimaler Auswirkung. Sie können die Auswahl sogar für eine Read-Replica-Datenbank ausführen, um die Auswirkungen auf die Leistung weiter zu verringern. In meinem Szenario wurde eine Benutzerklasse, die in der letzten Stunde nicht aktiv war, abgemeldet, sodass der Job stündlich ausgeführt wurde. Die andere Benutzerklasse, die nach 3 Monaten gelöscht wurde, wurde in einem Job gelöscht, der über Nacht ausgeführt wurde, da er mehr Vorgänge ausführte und mehr Auswirkungen auf die Serverressourcen hatte.

Wenn Sie Sitzungsdaten wirklich 2 Jahre lang speichern müssen, ist das in Ordnung. Sie könnten jedoch überlegen, ob Sie die Daten stattdessen im Cookie anstatt in der Sitzung speichern können. Auf diese Weise bleibt Ihre Sitzungstabelle leicht und Sie können den Benutzer im Cookie weiterhin verfolgen. Wenn Sie beispielsweise einen Kanal verfolgen möchten, der den Benutzer auf die Website gebracht hat, können Sie diese Kanalinformationen einfach in ihrem Cookie anstelle von $_SESSION Speichern. Wenn Sie vermeiden können, eine Sitzung zu generieren/beizubehalten, verschwindet das Skalierbarkeitsproblem.

Beachten Sie, dass viele Spinnen und Bots erheblichen Datenverkehr generieren und sich in Bezug auf Sitzungen schlecht verhalten: Sie verwerfen möglicherweise Cookies und generieren effektiv eine neue Sitzung für jede Seitenanforderung, wenn Ihre App dies tut. Sie können entweder ein Bot-Blocking/Caching-Netzwerk (wie Cloudflare) vorlegen oder einfach planen, die Sitzungstabelle regelmäßig zu analysieren und Sitzungen aus diesen Bots basierend auf einer IP-Adresse zu löschen.

Ich würde zu diesem Zweck keinen Memcache vorschlagen, sondern eine SQL-Datenbank (möglicherweise eine dedizierte Datenbankinstanz) oder Redis. Memcache wird als temporärer Datenspeicher optimiert. Sie möchten absichtlich einen dauerhaften Datenspeicher, den SQL oder Redis bereitstellen.

1
greggles

Nähere dich einem,

  1. Erhöhen Sie die Sitzungs- und Cookie-Lebensdauer nach Bedarf.
  2. Sitzung von dateibasierten Sitzungen in Memcached verschieben. Dies kann in der php.ini erfolgen.

Im Grunde geben Sie die längste Sitzung für alle Benutzer. Und dann können Sie vielleicht eine Regel oder einen Cronjob schreiben, um die Sitzungen der Benutzer der Rollen, für die Sie eine kürzere Zeitspanne benötigen, ungültig zu machen.

Ansatz zwei, ich denke besser https://www.drupal.org/project/persistent_login

Siehe: http://www.jaspan.com/improved_persistent_login_cookie_best_practice

0
esafwan