A Better Way to Manage the Rails Secret Token

Re:A Better Way to Manage the Rails Secret Token by gingerlime on Monday May 20, 2013 @04:09AM (#5736490)

also, in config/initializers/secret_token.rb:

   # Your secret key for verifying the integrity of signed cookies.

Does this mean that if you use redis/db-backed sessions you can safely ignore this secret_token parameter completely or even delete this initializer?

UPDATE: I just tried to remove it from our environment, and everything seems fine. Unless I'm missing something out, I'd say that's a far better and easier solution overall. It gives you much better control over you session + you don't have to worry about this configuration variable.

[ Parent | on HN ]

Re:A Better Way to Manage the Rails Secret Token by davesims on Monday May 20, 2013 @10:13AM (#5737776)

Since it's not only used for session cookies, I'd keep it around, on the off chance I ever wanted a signed cookie, like:

  cookies.signed['some-id'] = model.id

Rails will use the secret here too.

[ Parent | on HN ]

Re:A Better Way to Manage the Rails Secret Token by gingerlime on Monday May 20, 2013 @10:44AM (#5737921)

just curious: when would you need a signed cookie though? i.e. What need does it fulfil that neither the session store nor your database do?

[ Parent | on HN ]

Re:A Better Way to Manage the Rails Secret Token by davesims on Monday May 20, 2013 @12:50PM (#5738599)

I dunno, good question. Maybe something like this: there's some cases where I'll prefer cookies to session data, esp if it's non-volatile data that I can take or leave, like convenience values for the user on the js side, "last selected item" or the like.

I don't necessarily want that data in my session, or as a user attribute that I have to migrate the DB for. If it's a pkid or something that isn't necessarily sensitive, but I also don't want it to be too easy to get at, I might use a signed cookie.

Now, I've never actually done this... ;p

[ Parent | on HN ]