Wait a minute. It would be bad if deployed across multiple servers, load balanced, etc. All the keys would be different. Can't do that. right?
On Wednesday, May 21, 2014 8:28:12 AM UTC-5, Lee Hambley wrote: > > I have to ask: What are the downsides to regenerating the production >> secret_key_base during every deploy of the application? How are the end >> users impacted? > > > I'd imagine it'd invalidate all session keys > > Lee Hambley > -- > http://lee.hambley.name/ > +49 (0) 170 298 5667 > > > On 21 May 2014 15:09, Steve Smith <residen...@gmail.com <javascript:>>wrote: > >> I have to ask: What are the downsides to regenerating the production >> secret_key_base during every deploy of the application? How are the end >> users impacted? >> >> >> On Wednesday, May 14, 2014 8:31:49 AM UTC-5, Bruno Sutic wrote: >>> >>> Hi, >>> what you say is true and that workflow might work for you. >>> >>> Here's how the tricky scenario might look: >>> >>> - you *want* to have `secrets.yml` stored in git. That way a new >>> developer on the team, can just clone the repo and start working without >>> worrying about development secrets >>> - on the other hand, even though `secrets.yml` for development are >>> in git and "visible", you don't ever want to store production secrets. >>> So >>> it seems, rails suggests keeping production secrets in environment vars. >>> >>> With this approach, the tutorial from a couple posts back makes sense. >>> >>> Now I'm not completely sure this is the best approach too. What if, for >>> example, you want to keep development S3 credentials in `secrets.yml`? >>> Even for development, that leaves a lot of opportunity for abuse if keys >>> are stored in git and the repo is public. >>> >>> With all this talk, and circling around, maybe the simplest solution is >>> the best, so as Hassan said: >>> - do not keep `secrets.yml` in your version control >>> - just symlink `shared/secrets.yml` for remote server/production >>> >>> On Friday, May 9, 2014 6:34:40 PM UTC+2, hassan wrote: >>>> >>>> On Fri, May 9, 2014 at 9:23 AM, Bruno Sutic <bruno...@gmail.com> >>>> wrote: >>>> > Here's another interesting writeup on this topic: >>>> > http://blog.intercityup.com/deploying-app-env-variables- >>>> with-rbenv-passenger-and-capistrano/ >>>> >>>> I really don't understand the point of all this futzing around. Per the >>>> above, now you have a file 'shared/.rbenv-vars' which needs to be >>>> symlinked into your app. >>>> >>>> Why not just symlink 'shared/secrets.yml' into your app to start with? >>>> >>>> Either way, all of your "secret sauce" is in a file in a directory on >>>> the >>>> server. >>>> >>>> Or am I missing something? >>>> -- >>>> Hassan Schroeder ------------------------ hassan.s...@gmail.com >>>> http://about.me/hassanschroeder >>>> twitter: @hassan >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Capistrano" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to capistrano+...@googlegroups.com <javascript:>. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/capistrano/5984604b-aa64-4ccb-8cd7-381d76ce3729%40googlegroups.com<https://groups.google.com/d/msgid/capistrano/5984604b-aa64-4ccb-8cd7-381d76ce3729%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/71078c49-6e16-4754-8b07-fb44fc1e8cef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
