2013-06-28 1 views
4

Я изучаю структуру Sinatra &, разрабатывая систему входа в систему. Я наткнулся на два способа использования файлов cookie.Разница в содержании файлов cookie с использованием сеанса Sinatra и стойки :: Session :: EncryptedCookie

Простой Синатра встроенный способ:

enable :sessions 
set :session_secret, 'random-key' 

Этот подход дает следующее содержание печенья при входе в систему (используется session.inspect, чтобы получить выход):

{"session_id"=>"6be0b9a31831604ba51114d265ba952482e0b2da6ced6c54e15ebe7f212858ca", 
"tracking"=>{"HTTP_USER_AGENT"=>"b8c1e8f89eeaea0b825bed0d811f0c7678e98c74", 
"HTTP_ACCEPT_ENCODING"=>"a0bfc876d68fe7aea700da5ea8925abac6f2f794", 
"HTTP_ACCEPT_LANGUAGE"=>"dd065ed263c67d799f943ab6c39b55c5e008cbb5"}, 
"csrf"=>"b480324f510e4f391d15cee8236a8fb74a5aaa5ce2f9ad38e4dbb025a823b16e",  
"name"=>"john"} 

Другой подход использует зашифрованный куки:

require 'sinatra' 
require 'encrypted_cookie' 

use Rack::Session::EncryptedCookie, :secret => "random-key" 

Но этот подход создает следующие файлы cookie con Палатка при входе в систему (используется session.inspect здесь):

{:name=>"john"} 

Почему enable :sessions создает такое большое печенье со всей этой информацией & почему требуется это (особенно те HTTP _... части?) Поскольку Rack::Session::EncryptedCookie не генерируя любое из них.

Считаете ли вы, что использование enable :sessions должно быть предпочтительным, поскольку оно имеет токен csrf & session id? Или вы считаете, что Rack::Session::EncryptedCookie достаточно, поскольку он зашифрован?

я следующие версии драгоценных камней установлены:

encrypted_cookie (0.0.4) 
rack (1.5.2) 
rack_csrf (2.4.0) 
sinatra (1.4.3) 
thin (1.5.1) 

Пожалуйста, скажите мне, если вам нужна дополнительная информация ...

ответ

0

Поскольку Rack::Session::EncryptedCookie требует, чтобы ваш секрет, по меньшей мере 16 битам. В README, они рекомендуют использовать OpenSSL для генерации секрета, например, так:

ruby -ropenssl -e "puts OpenSSL::Random.random_bytes(16).inspect" 

Если вы откроете инспектор, вы увидите печенье под названием «rack.session», и его содержание запутанным.

+0

Yea. Я знаю это :). Но мой вопрос: предпочитаете ли вы включать: сеансы, потому что он создает идентификатор сессии id & csrf и все эти дополнительные данные? или вы предпочитаете «Rack :: Session :: EncryptedCookie», потому что его зашифрованные и не нужны эти дополнения? – Rahul

+0

Вы используете любое другое промежуточное ПО? Выполнение 'enable: sessions', а затем проверка сеанса дает мне результат, аналогичный выводу« Rack :: Session :: EncryptedCookie ». Лично я использую «Rack :: Session :: Cookie» в качестве промежуточного программного обеспечения и задаю секрет этого (загруженный из переменной среды). –

+0

Хммм. При использовании подхода 'enable: sessions' я не использую никакого другого промежуточного программного обеспечения. BTW, я отредактировал вопрос, чтобы включить версии необходимых драгоценных камней. У меня может быть другая версия какого-то драгоценного камня по сравнению с вами. Любые подсказки? – Rahul

1

Потому что Sinatra будет использовать rack-protection промежуточное программное обеспечение при включении :sessions. Это делает cookie больше, но более безопасным.

Соответствующий фрагмент кода:

def setup_default_middleware(builder) 
    builder.use ExtendedRack 
    builder.use ShowExceptions  if show_exceptions? 
    builder.use Rack::MethodOverride if method_override? 
    builder.use Rack::Head 
    setup_logging builder 
    setup_sessions builder 
    setup_protection builder 
end 

def setup_sessions(builder) 
    return unless sessions? 
    options = {} 
    options[:secret] = session_secret if session_secret? 
    options.merge! sessions.to_hash if sessions.respond_to? :to_hash 
    builder.use session_store, options 
end 

def setup_protection(builder) 
    return unless protection? 
    options = Hash === protection ? protection.dup : {} 
    options = { 
    img_src: "'self' data:", 
    font_src: "'self'" 
    }.merge options 

    protect_session = options.fetch(:session) { sessions? } 
    options[:without_session] = !protect_session 

    options[:reaction] ||= :drop_session 

    builder.use Rack::Protection, options 
end 
  • sessions? возвращает истину, если вы включите: сессии
  • session_store является Rack::Session::Cookie по умолчанию

Разница между Rack::Session::EncryptedCookie

То есть, если вы хотите использовать Rack::Session::EncryptedCookie с rack-production, это можно легко сделать с помощью:

enable :sessions 
set :session_store, Rack::Session::EncryptedCookie 

FYI, так как encrypted_cookie не является отсутствие некоторых функций (секрет вращения, пользовательский сериализатор, и т.д.) и больше не на обслуживании , Я сделал another one, чтобы заменить его.

Надеюсь, это поможет.

0

Как я знаю, при использовании Rack :: Session :: Cookie в Sinatra и записи session_secret в качестве переменной окружения, созданный сеанс не будет уничтожаться после развертывания проекта. Я думаю, что это риск в приложении с одной страницей.