Difference in cookie content using Sinatra and Rack :: Session :: EncryptedCookie

Question

I am studying the structure of Sinatra and developing a login system. I came across two ways to use cookies.

Simple built-in Sinatra method:

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

This approach creates the following cookie at login time (using session.inspect to get the result):

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

Another approach is to use an encrypted cookie:

 require 'sinatra' require 'encrypted_cookie' use Rack::Session::EncryptedCookie, :secret => "random-key" 

But this approach leads to the following cookie contents on login ( session.inspect used here):

 {:name=>"john"} 

Why enable :sessions creates such a large cookie with all this information and why it is needed (especially those parts of HTTP _...?) Since Rack::Session::EncryptedCookie does not generate any of them.

Do you think using enable :sessions should be preferred since it has a csrf token and session id? Or do you think that Rack::Session::EncryptedCookie enough because it is encrypted?

I have the following versions of installed stones:

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

Please tell me if you need more information ...

Answer 1

Because Sinatra will use rack-protection middleware when you enable :sessions . This makes cookies bigger, but more secure.

Corresponding fragment:

 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? returns true if you enable: sessions
• session_store default Rack::Session::Cookie

Difference Between Rack::Session::EncryptedCookie

That is, if you want to use Rack::Session::EncryptedCookie with rack-production , this is easy to do:

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

FYI, since encrypted_cookie is the lack of some functions (secret rotation, custom serializer, etc.) and is no longer supported, I did another one to replace it.

Hope this helps.

Answer 2

Because Rack::Session::EncryptedCookie requires your secret to be at least 16 bits. In README, they recommend using OpenSSL to generate sensitive information, for example:

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

If you open your inspector, you will see a cookie named "rack.session" and its contents are messy.

Answer 3

As I know, when using Rack :: Session :: Cookie in Sinatra and session_secret record as an environment variable, the created session will not be destroyed after the project is deployed. I think this is a risk in a single page application.