2011-09-08 6 views
8

Tengo una aplicación web que es parte de Rails y parte Backbone. Algunas cosas como un sistema de comentarios que he implementado están escritas principalmente en Javascript en el lado del cliente. El backend Rails simplemente maneja la persistencia pasando JSON hacia adelante y hacia atrás.¿Cómo administro la sesión de usuario actual en el lado del cliente?

Cuando renderizo páginas desde el servidor, manejo quién puede ver lo que es fácil. Puedo decir cosas tales como

<li class="comment"> 
    <span class="comment_text"><%= @comment.text %></span> 
    <% if user_signed_in? and current_user == @comment.author %> 
    <a class="delete" href="some delete url">Delete Comment</a> 
    <% end %> 
</li> 

Y eso sólo hará que el enlace para eliminar un comentario particular, si el usuario actual es el autor del comentario. No hay problema.

Sin embargo, ahora que estoy renderizando comentarios en el lado del cliente usando JavaScript templates (que están en caché afaik), no tengo acceso a current_user. No puedo decir si el usuario que está usando mi aplicación es el autor del comentario o no, así que no puedo controlar lo que ve.

Claro, no podrá eliminar el comentario de ninguna manera porque yo también autorizo ​​en el servidor, pero preferiría no mostrarlo en primer lugar.

¿Cómo puedo lograr esto?

Me encantaría algunos enlaces a los recursos sobre este tema, así como las respuestas, porque parece que no puedo encontrar ninguno, aunque me parece que este es un tema que debería haber sido cubierto en innumerables blogs.

Respuesta

7

prefiero utilizar el enfoque siguiente.

En primer lugar, en su diseño, generada en el lado del servidor, dejan pasar los datos del usuario actual que necesitará en el lado del cliente:

<script type="text/javascript"> 
    window.currentUser = { 
     id : "<%=current_user.id%>" 
    } 
</script> 

será accesible en sus plantillas EJS. Ahora en plantilla, se puede hacer la misma comprobación como en el lado del servidor:

<% if (window.currentUser && window.currnetUser.id == comment.author.id) { %> 
    <a class="delete" href="some delete url">Delete Comment</a> 
<% } %> 
+1

¿Este enfoque es más fácil de usar? El usuario puede cambiar la ID del usuario actual – ecleel

+0

. Es seguro de usar, siempre que tenga protecciones del lado del servidor en su lugar, de modo que incluso si el usuario cambia la identificación e intenta presionar eliminar, obtendrá un error 401 no autorizado. Mostrar y no mostrar el botón Eliminar es para comodidad del usuario, no de seguridad. – AwDogsGo2Heaven

0

Ryan Bates describe una práctica común para ese caso, déjame explicarte. Ayuda con Dynamic Page Caching, cuando utiliza el almacenamiento en caché de páginas, pero necesita obtener algo del servidor y manejarlo.

Está a punto de presentar la página sin el enlace "Eliminar", luego obtener una solicitud para verificar si la sesión del usuario o no y asignar el resultado a una variable.

Una de aplicación, un poco más profundo:

# controller 
    class UserSessionController < ActionController::Base 
    skip_before_filter :require_user, :only => [:new, :create, :user_sign_in] 

    def user_sign_in 
     if current_user 
     render :text => 'success' 
     else 
     render :text => 'false', :status => 403 
     end 
    end 
    end 


    class CommentsController < ApplicationController 
    def has_right 
     current_user == @comment.author 
    end 
    end 


    # view 
    <% javascript_tag do %> 
    var a = $.getJSON('/user_session/user_sign_in', function(data){ 
     console.log(data) 
    }); 

    <% end %> 

Entonces manejar el resultado y Ocultar/Mostrar comentarios divs.

+0

Haz más Javascript a lo más que puede, pensar en el lado del servidor como "proveedor de API" en su mayoría – Anatoly

+0

En realidad no hay un patrón mejor que ¿esta? Si, por ejemplo, hay cientos de comentarios en la página, entonces cada carga de página simplemente va a golpear al servidor. – JofoCodin

+0

a la derecha, no hay una buena manera de comprobar el permiso para cada comentario obteniendo cientos de veces del servidor. Puede tratar de obtener JSON con una estructura de 'comentarios': {id: '1', permission: true} y desarrollar una lógica basada en la estructura de datos JSON – Anatoly

2

Esto a veces se denomina personalización del lado del cliente. Implica el uso de clases de CSS para ocultar y mostrar elementos basados ​​en un valor que javascript obtiene de una cookie o una solicitud de Ajax.

Prefiero configurar el estado del usuario, el nombre y otros datos clave en una cookie que se establece en un middleware de rack que envuelve la capa de almacenamiento en caché. De esta manera, la lógica de la sesión del usuario puede aislarse de los datos en caché. Luego uso javascript para leer esta cookie y modificar la página según sea necesario. En el caso del ejemplo de comentarios que usted dio, representaría cada comentario con un resumen de su ID (o solo el ID, si no está preocupado por las implicaciones de seguridad) en un atributo de datos, como por ejemplo:

<div class="comment_203948">...</div> 

y almacena los ids de los comentarios de un usuario en la cookie antes mencionada. Luego, javascript lee la cookie y encuentra todos los comentarios con esos ID, y muestra el enlace 'eliminar' para ellos.

Un problema común con este enfoque involucra lo que sucede cuando la cookie se desborda, como sucedería en este ejemplo con un comentarista prolífico. Otro enfoque es usar ajax para obtener los datos JSON relevantes del usuario y luego almacenarlos en caché en el almacenamiento local.Me gusta combinar eso con mantener una versión de los datos JSON del usuario en una cookie que se puede actualizar en el lado del servidor con callbacks after_save y otras estrategias de caché y caducidad. Entonces, Javascript simplemente compara el estado del JSON del usuario que se encuentra en el almacenamiento local con la versión en la cookie y lo actualiza a través de una solicitud ajax cuando está desactualizado.

Para algunos consejos adicionales sobre el lado del cliente Personalización, vea este post en "lado del cliente personalización caché": http://www.tumblr.com/tagged/caching

y éste: http://pivotallabs.com/users/nick/blog/articles/297-making-rails-wicked-fast-pagecaching-highly-personalized-web-pages

Cuestiones relacionadas