Ich habe eine Web-App, die Teil von Rails ist und Teil Backbone . Einige Dinge wie ein Kommentarsystem, das ich implementiert habe, werden meistens in Javascript auf der Client-Seite geschrieben. Das Rails-Backend behandelt einfach die Persistenz, indem es JSON vor und zurückgibt.
Wenn ich Seiten vom Server rende, wird mit dem Umgang damit gerechnet, was einfach ist. Ich kann Dinge sagen wie
%Vor%Damit wird nur der Link zum Löschen eines bestimmten Kommentars gerendert, wenn der aktuelle Benutzer der Autor des Kommentars ist. Kein Problem.
Aber jetzt, wo ich Kommentare auf der Client-Seite mit JavaScript-Vorlagen (die im Cache gespeichert sind), habe ich nicht Zugriff auf current_user . Ich kann nicht sagen, ob der Benutzer, der gerade meine App benutzt, der Autor des Kommentars ist oder nicht, also kann ich nicht kontrollieren, was er sieht.
Sicher, er wird den Kommentar nicht löschen können, weil ich auch auf dem Server autorisiere, aber ich würde den Link lieber nicht zeigen.
Wie kann ich das erreichen?
Ich würde einige Links zu Ressourcen zu diesem Thema sowie Antworten lieben, weil ich keine finden kann, obwohl es mir scheint, als wäre dies ein Thema, das in unzähligen Blogs hätte behandelt werden sollen. p>
Ich bevorzuge den folgenden Ansatz.
Zuerst geben Sie in Ihrem Layout, das auf der Serverseite generiert wird, die aktuellen Daten des Benutzers weiter, die Sie auf der Client-Seite benötigen:
%Vor%Es wird in Ihren EJS-Vorlagen verfügbar sein. Jetzt können Sie in der Vorlage die gleiche Überprüfung wie auf der Serverseite vornehmen:
%Vor%Dies wird manchmal Client-Personalisierung genannt. Es beinhaltet die Verwendung von CSS-Klassen zum Ausblenden und Anzeigen von Elementen, die auf einem Wert basieren, den JavaScript von einem Cookie oder einer AJAX-Anfrage erhält.
Ich bevorzuge die Einstellung von Benutzerstatus, Name und anderen Schlüsseldaten in einem Cookie, der in einer Rack-Middleware festgelegt ist, die den Cache-Layer umschließt. Auf diese Weise kann die Logik für Benutzersitzung von zwischengespeicherten Daten isoliert werden. Dann benutze ich Javascript, um diesen Cookie zu lesen und die Seite nach Bedarf zu ändern. Im Fall des von Ihnen angegebenen Kommentarbeispiels würde ich jeden Kommentar mit einem Auszug seiner ID (oder nur der ID, wenn Sie sich nicht um die Sicherheitsauswirkungen sorgen) in einem Datenattribut darstellen, wie folgt:
> %Vor%und speichern Sie die IDs der Kommentare eines Nutzers im oben genannten Cookie. Dann liest javascript den Cookie und findet alle Kommentare mit diesen IDs und zeigt den "Löschen" -Link für sie an.
Ein häufiges Problem bei diesem Ansatz ist, was passiert, wenn der Cookie überläuft, wie es in diesem Beispiel mit einem produktiven Kommentator passieren würde. Ein anderer Ansatz besteht darin, Ajax zu verwenden, um die relevanten JSON-Daten des Benutzers abzurufen und diese dann im lokalen Speicher zwischenzuspeichern. Ich kombiniere das gerne mit der Speicherung einer Version der JSON-Daten des Benutzers in einem Cookie, das auf der Serverseite mit after_save-Callbacks und anderen Cache-Ablaufstrategien aktualisiert werden kann. Javascript vergleicht dann einfach den Status des JSON des Benutzers, der im lokalen Speicher gefunden wird, mit der Version im Cookie und aktualisiert diesen JSON über eine Ajax-Anforderung, wenn er veraltet ist.
Weitere Tipps zur Personalisierung von Clients finden Sie in diesem Beitrag unter "clientseitige Cache-Personalisierung": Ссылка
und dieser: Ссылка
Ryan Bates beschreibt eine übliche Praxis für diesen Fall, lass mich das erklären. Es hilft mit Dynamic Page Caching , wenn Sie Seiten-Caching verwenden, aber etwas von der Server-Seite und Handle es.
Ist im Begriff, Seite ohne Link "Delete" zu rendern, dann eine Anfrage zu bekommen, um zu überprüfen, ob Benutzersitzung oder nicht und das Ergebnis einer Variablen zuweisen.
Eine der Implementierungen, ein bisschen tiefer:
%Vor%Behandle dann das Ergebnis und blende / zeige Kommentare divs.
Tags und Links javascript ruby-on-rails authentication backbone.js