I'm neutral on the feature of dynamic secret tokens, but I'll weigh in on your implementation choice. Please don't use the callable approach for it. That's appropriate in a more functional language, but in Ruby, we'd like things to be objects and use semantically meaningful message names. The problem with passing around procs is that you can't tell anything about them - they are just procs, and calling them looks like like calling any other proc. A simple duck-type for secret tokens will give you more flexibility and make it easier for others to understand and work with.
-- Josh Susser http://blog.hasmanythrough.com On Sat, Mar 29, 2014 at 8:23 AM, Bert Goethals <bertgoeth...@gmail.com>wrote: > I've been looking into this and it is possible, however I don't think it > is needed. > I'm going to describe how it's possible in rails 3 and 4; and why I don't > think it's needed in rails 4. > > Rails 3: > > In rails 3 action_dispatch uses the secret_token that is added to the > request env. This is then used by other parts of the application. If you > want to make this dynamic it's as easy as changing the value of > "action_dispatch.secret_token" key in the request env early in the > middleware stack. > > Rails 4: > > In Rails 4 there is quite a bit more going on. Action_dispatch is now > using: secret_token, secret_key_base, key_generator, http_auth_salt, > signed_cookie_salt, encrypted_cookie_salt, and > encrypted_signed_cookie_salt. Just like in rails 3 these values are fixed > for the entire application. The "bad" thing here is that the key_generator > is initialised once with either the secret_token or secret_key_base. Even > if we change these values later with middleware the generator will keep > using the values it was initialised with. > > It's perfectly possible to swap out the generator on a per request basis, > just like swapping the secret_token in rails 3. I have no idea what the > impact of that would be, but I think it would be minimal. An alternative > would be to change the salts per request. I think this could even be better > than switching out the generator entirely; and can be easily achieved with > some middleware. > > I hope this info is useful for others! > > Maybe we can explain this in the action_dispatch docs? > > On Friday, March 28, 2014 4:02:58 PM UTC+1, Bert Goethals wrote: >> >> Hi all, >> >> Security is always a hot topic, and in our company especially. >> We where looking into the secret tokens. And we think we can do a step >> better than an "secrets.yml" file. >> >> The fact is that system administrators still have access to the secret >> token, and that is not always acceptable. >> Replacing the secret token each time an admin leaves, is not a viable >> solution. So we fought, how about a dynamic token? >> >> Proposing to make the token "callable". Besides being a string, the token >> could be a proc or anything responding to call, receiving the request >> object. >> This allows the implementer to dynamically change the token. >> >> This can be useful to have a separate token per domain, very useful in >> multi tenant applications. >> >> If there is intrest in this, I'm willing to develop it as well! >> >> What do you think? >> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-core+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
