Earlier quoted context omitted.
> I always assumed cryptography is slower than IO Cryptography is a CPU-bound operation that often has specialized hardware support. Here's a rule of thumb: in modern computing, IO incurs a greater cost than pretty much anything you can do locally on-CPU. IO is incredibly expensive: cryptography, not so much. If you pipeline your crypto operations and disk fetches, you won't increase response latency at all.
Ruby has a reputation for slowness ([citation needed]?) so is the cryptographic stuff implemented in the language itself or via C-or-equivalent foreign library? I could understand the "too slow, must avoid" kneejerk reaction if it's all in Ruby, even if the reputation is no longer deserved. Human nature.
Rails' CookieStore isn't broken
21–30 of 33 posts
Re: Rails' CookieStore isn't broken
#22Re: Rails' CookieStore isn't broken
#23The CookieStore isn't broken but you do need to add code to fix the issue? I have no experience with Rails but I really hadn't expected that sessions would be client-side only.
Re: Rails' CookieStore isn't broken
#24Earlier quoted context omitted.
> Especially when cookies are easily stolen using something like Firesheep Who in late 2013 (with enough clue to care about this issue) is still using non-secure-flag cookies for anything even remotely important?!
As far as I'm Rails doesn't use secure-flag cookies by default; you need to have something like this in config/initializers/session_store.rb: local_env = !(Rails.env.test? || Rails.env.development?) MyApp::Application.config.session_store(:cookie_store, { key: '_my_app_session', secure: local_env, # ... or just true }) Yes, somebody who has gone looking for this can find it, but I'd argue that Rails should at least g…
Re: Rails' CookieStore isn't broken
#25Earlier quoted context omitted.
I'm suggesting that site operators need to use HTTPS. It doesn't matter if you use Rails, PHP, Node.js, whatever. USE HTTPS. NEVER USE HTTP. It's as simple as that. Never assume that anything transmitted over HTTP is safe, because that assumption will come back to bite you.
Exactly - use force_ssl true in the case of Rails.
Re: Rails' CookieStore isn't broken
#26I have to declare Inigo Montoya on the use of the word "trivially" in that article, though I see from a comment here that someone's already issued a patch that I presume will get included in the next version, so perhaps it will become trivial shortly.
Re: Rails' CookieStore isn't broken
#27Earlier quoted context omitted.
Exactly - use force_ssl true in the case of Rails.
do you ever get a headache from sitting in this echo chamber all day?
Are you suggesting not using SSL?
If not, can you clarify your point?
Thanks.
Re: Rails' CookieStore isn't broken
#28I have to declare Inigo Montoya on the use of the word "trivially" in that article, though I see from a comment here that someone's already issued a patch that I presume will get included in the next version, so perhaps it will become trivial shortly.
Wasn't that Vizzini?
Re: Rails' CookieStore isn't broken
#29What do you gain by using the cookie store with this database component, over just using the active record store to begin with? (The ActiveRecord store used to be the default back in... Rails 2.0?)
Re: Rails' CookieStore isn't broken
#30The CookieStore isn't broken but you do need to add code to fix the issue? I have no experience with Rails but I really hadn't expected that sessions would be client-side only.
FWIW, the fact that the default session store is client-side only is mentioned in the overview for beginners: http://guides.rubyonrails.org/action_controller_overview.htm...