[Possible Feature Request] Should app fail to boot if secrets for current environment can not be loaded?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Possible Feature Request] Should app fail to boot if secrets for current environment can not be loaded?

Chris S
I’ve just suffered a long 20 minutes trying to debug why an app was broken: Missing its Rails.application.secrets, even though secrets.yml was in place and "looked" OK.

The problem was a tiny whitespace glitch in my YAML, which meant the app was failing to load the secrets for its current environment.

Should this be considered a bug? Does it make sense for the app to continue booting if it can’t find its secrets?

I’d happily file a pull request for this if s., I’ve looked at the relevant code and it doesn’t seem to be a difficult change to make, but I wouldn’t want to commit the effort if I’m wrong about this and there are circumstances where it makes sense to plough on even if secrets can’t be loaded.

Let me know,
Chris.

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Possible Feature Request] Should app fail to boot if secrets for current environment can not be loaded?

Mohamed Wael Khobalatte
Was the glitch in the YAML structure itself (which normally would throw a parse exception and the app won't start), or was it a glitch in a value (value is "\sabc" vs "abc")? The latter is almost impossible to solve, considering that it hosts a wide variety of values, from API keys to your own secrets.

The way I deal with it is to try and figure out which values are just too important for the app, say a cache host credentials, then attempt a start of that service in an initializer, aborting the start the entire application of no values are found in the secrets file. 

On Fri, Mar 17, 2017 at 9:28 AM, Chris S <[hidden email]> wrote:
I’ve just suffered a long 20 minutes trying to debug why an app was broken: Missing its Rails.application.secrets, even though secrets.yml was in place and "looked" OK.

The problem was a tiny whitespace glitch in my YAML, which meant the app was failing to load the secrets for its current environment.

Should this be considered a bug? Does it make sense for the app to continue booting if it can’t find its secrets?

I’d happily file a pull request for this if s., I’ve looked at the relevant code and it doesn’t seem to be a difficult change to make, but I wouldn’t want to commit the effort if I’m wrong about this and there are circumstances where it makes sense to plough on even if secrets can’t be loaded.

Let me know,
Chris.

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



--
Wael Khobalatte

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Possible Feature Request] Should app fail to boot if secrets for current environment can not be loaded?

Chris S
Good points.

I could have been more explicit about my exact problem

The glitch was that I’d indented `production`, so that the YAML parser was considering it a sub-key of `staging`. Obviously, accidentally deleting a character (`producion`, etc) would have similar effects.

I agree it’s probably scope-creep to deal with malformed keys anywhere in the file, but it doesn’t seem outrageous to check if there’s a top level key which matches the current RAILS_ENV, and bail if not?

Chris.


On Fri, Mar 17, 2017 at 2:52 PM, Mohamed Wael Khobalatte <[hidden email]> wrote:
Was the glitch in the YAML structure itself (which normally would throw a parse exception and the app won't start), or was it a glitch in a value (value is "\sabc" vs "abc")? The latter is almost impossible to solve, considering that it hosts a wide variety of values, from API keys to your own secrets.

The way I deal with it is to try and figure out which values are just too important for the app, say a cache host credentials, then attempt a start of that service in an initializer, aborting the start the entire application of no values are found in the secrets file. 

On Fri, Mar 17, 2017 at 9:28 AM, Chris S <[hidden email]> wrote:
I’ve just suffered a long 20 minutes trying to debug why an app was broken: Missing its Rails.application.secrets, even though secrets.yml was in place and "looked" OK.

The problem was a tiny whitespace glitch in my YAML, which meant the app was failing to load the secrets for its current environment.

Should this be considered a bug? Does it make sense for the app to continue booting if it can’t find its secrets?

I’d happily file a pull request for this if s., I’ve looked at the relevant code and it doesn’t seem to be a difficult change to make, but I wouldn’t want to commit the effort if I’m wrong about this and there are circumstances where it makes sense to plough on even if secrets can’t be loaded.

Let me know,
Chris.

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



--
Wael Khobalatte

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Possible Feature Request] Should app fail to boot if secrets for current environment can not be loaded?

Mohamed Wael Khobalatte
Yes I think that would be a great addition. You will like reading this discussion: https://github.com/rails/rails/pull/17175. Extending one of the proposals there to require RAILS_ENV by default will solve your problem I think. 

On Fri, Mar 17, 2017 at 11:39 AM, Chris S <[hidden email]> wrote:
Good points.

I could have been more explicit about my exact problem

The glitch was that I’d indented `production`, so that the YAML parser was considering it a sub-key of `staging`. Obviously, accidentally deleting a character (`producion`, etc) would have similar effects.

I agree it’s probably scope-creep to deal with malformed keys anywhere in the file, but it doesn’t seem outrageous to check if there’s a top level key which matches the current RAILS_ENV, and bail if not?

Chris.


On Fri, Mar 17, 2017 at 2:52 PM, Mohamed Wael Khobalatte <[hidden email]> wrote:
Was the glitch in the YAML structure itself (which normally would throw a parse exception and the app won't start), or was it a glitch in a value (value is "\sabc" vs "abc")? The latter is almost impossible to solve, considering that it hosts a wide variety of values, from API keys to your own secrets.

The way I deal with it is to try and figure out which values are just too important for the app, say a cache host credentials, then attempt a start of that service in an initializer, aborting the start the entire application of no values are found in the secrets file. 

On Fri, Mar 17, 2017 at 9:28 AM, Chris S <[hidden email]> wrote:
I’ve just suffered a long 20 minutes trying to debug why an app was broken: Missing its Rails.application.secrets, even though secrets.yml was in place and "looked" OK.

The problem was a tiny whitespace glitch in my YAML, which meant the app was failing to load the secrets for its current environment.

Should this be considered a bug? Does it make sense for the app to continue booting if it can’t find its secrets?

I’d happily file a pull request for this if s., I’ve looked at the relevant code and it doesn’t seem to be a difficult change to make, but I wouldn’t want to commit the effort if I’m wrong about this and there are circumstances where it makes sense to plough on even if secrets can’t be loaded.

Let me know,
Chris.

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



--
Wael Khobalatte

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



--
Wael Khobalatte

--
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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [Possible Feature Request] Should app fail to boot if secrets for current environment can not be loaded?

Chris S
I like the ideas in that PR, although I’m not 100% qualified to comment on them (we don’t use env vars).

It does raise the problem that secrets.yml is lazily evaluated, so I don’t know if my suggested check would/could run at boot-time :/

Chris

On Fri, Mar 17, 2017 at 3:49 PM, Mohamed Wael Khobalatte <[hidden email]> wrote:
Yes I think that would be a great addition. You will like reading this discussion: https://github.com/rails/rails/pull/17175. Extending one of the proposals there to require RAILS_ENV by default will solve your problem I think. 

On Fri, Mar 17, 2017 at 11:39 AM, Chris S <[hidden email]> wrote:
Good points.

I could have been more explicit about my exact problem

The glitch was that I’d indented `production`, so that the YAML parser was considering it a sub-key of `staging`. Obviously, accidentally deleting a character (`producion`, etc) would have similar effects.

I agree it’s probably scope-creep to deal with malformed keys anywhere in the file, but it doesn’t seem outrageous to check if there’s a top level key which matches the current RAILS_ENV, and bail if not?

Chris.


On Fri, Mar 17, 2017 at 2:52 PM, Mohamed Wael Khobalatte <[hidden email]> wrote:
Was the glitch in the YAML structure itself (which normally would throw a parse exception and the app won't start), or was it a glitch in a value (value is "\sabc" vs "abc")? The latter is almost impossible to solve, considering that it hosts a wide variety of values, from API keys to your own secrets.

The way I deal with it is to try and figure out which values are just too important for the app, say a cache host credentials, then attempt a start of that service in an initializer, aborting the start the entire application of no values are found in the secrets file. 

On Fri, Mar 17, 2017 at 9:28 AM, Chris S <[hidden email]> wrote:
I’ve just suffered a long 20 minutes trying to debug why an app was broken: Missing its Rails.application.secrets, even though secrets.yml was in place and "looked" OK.

The problem was a tiny whitespace glitch in my YAML, which meant the app was failing to load the secrets for its current environment.

Should this be considered a bug? Does it make sense for the app to continue booting if it can’t find its secrets?

I’d happily file a pull request for this if s., I’ve looked at the relevant code and it doesn’t seem to be a difficult change to make, but I wouldn’t want to commit the effort if I’m wrong about this and there are circumstances where it makes sense to plough on even if secrets can’t be loaded.

Let me know,
Chris.

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



--
Wael Khobalatte

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



--
Wael Khobalatte

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