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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
