Как мне управлять текущим сеансом пользователя на стороне клиента? - PullRequest
8 голосов
/ 08 сентября 2011

У меня есть веб-приложение, которое является частью Rails и частью Backbone .Некоторые вещи, такие как система комментирования, которую я реализовал, написаны в основном на Javascript на стороне клиента.Бэкэнд Rails просто обрабатывает персистентность, передавая JSON взад и вперед.

Когда я рендерим страницы с сервера, я получаю информацию о том, кому это легко.Я могу сказать такие вещи, как

<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>

, и это только сделает ссылку для удаления конкретного комментария, если текущий пользователь является автором комментария.Нет проблем.

Однако теперь, когда я отрисовываю комментарии на стороне клиента, используя шаблоны JavaScript (которые кешируются), у меня нет доступа к current_user.Я не могу сказать, является ли пользователь комментария автором комментария или нет, поэтому я не могу контролировать то, что он видит.

Конечно, он не сможет удалить комментарий.в любом случае, потому что я авторизуюсь и на сервере, но я бы предпочел не показывать ссылку в первую очередь.

Как мне это сделать?

Мне бы очень хотелось, чтобы некоторые ссылки наресурсы по этой теме, а также ответы, потому что я не могу найти ни одного, хотя мне кажется, что эта тема должна была быть освещена в бесчисленных блогах.

Ответы [ 3 ]

7 голосов
/ 29 апреля 2012

Я предпочитаю использовать следующий подход.

Сначала в макете, созданном на стороне сервера, передайте данные текущего пользователя, которые вам понадобятся на стороне клиента:

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

Он будет доступен в ваших шаблонах EJS. Теперь в шаблоне вы можете выполнить ту же проверку, что и на стороне сервера:

<% if (window.currentUser && window.currnetUser.id == comment.author.id) { %>
    <a class="delete" href="some delete url">Delete Comment</a>
<% } %>
2 голосов
/ 05 апреля 2012

Иногда это называется персонализацией на стороне клиента. Он включает использование классов css для сокрытия и отображения элементов, основанных на значении, которое javascript получает из файла cookie или запроса ajax.

Я предпочитаю задавать пользовательское состояние, имя и другие ключевые данные в файле cookie, который устанавливается в промежуточное ПО стойки, которое оборачивает слой кэширования. Таким образом, логика для сеанса пользователя может быть изолирована от кэшированных данных. Затем я использую JavaScript, чтобы прочитать этот файл cookie и при необходимости изменить страницу. В случае примера комментариев, который вы привели, я бы отображал каждый комментарий с дайджестом его идентификатора (или просто идентификатора, если вас не интересуют последствия для безопасности) в атрибуте данных, например:

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

и сохраните идентификаторы комментариев пользователя в вышеупомянутом cookie. Затем javascript читает cookie и находит все комментарии с этими идентификаторами и показывает ссылку «удалить» для них.

Общая проблема с этим подходом заключается в том, что происходит, когда cookie переполняется, как это происходит в этом примере с плодотворным комментарием. Другой подход заключается в использовании ajax для извлечения соответствующих данных JSON пользователя, а затем для их кэширования в локальном хранилище. Мне нравится сочетать это с хранением версии данных JSON пользователя в файле cookie, который можно обновлять на стороне сервера с помощью обратных вызовов after_save и других стратегий истечения срока действия кэша. Затем Javascript просто сравнивает состояние JSON пользователя, найденного в локальном хранилище, с версией в файле cookie, и обновляет этот JSON с помощью запроса ajax, когда он устарел.

Дополнительные советы по персонализации на стороне клиента см. В этом посте в разделе «Персонализация кэша на стороне клиента»: http://www.tumblr.com/tagged/caching

и этот: http://pivotallabs.com/users/nick/blog/articles/297-making-rails-wicked-fast-pagecaching-highly-personalized-web-pages

0 голосов
/ 08 сентября 2011

Райан Бейтс описывает обычную практику для этого случая, позвольте мне объяснить.Это помогает с динамическим кэшированием страниц , когда вы используете кэширование страниц, но вам нужно получить что-то со стороны сервера и обработать его.

Собирается отобразить страницу без ссылки «Удалить», затемзапрос, чтобы проверить, является ли пользовательский сеанс или нет, и присвоить результат переменной.

Одна из реализаций, немного глубже:

   # 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 %>

Затем обработать результат и скрыть / показать комментариидивы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...