-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Insert Letsencrypt::Middleware dynamically #10
base: master
Are you sure you want to change the base?
Conversation
I've tested this in a production application and it works perfectly but if you'd like me to add a test I wouldn't mind. |
This is a nice idea! Thanks. I think it's definitely on the right lines. However I'm not happy about the gem making the assumption that you're only going to use it in production. What about securing a staging environment that runs Rails under a different environment? Is there another approach that would still keep this control but automate insertion position? |
We don't have to check for the environment, I was just mimicking your implementation since you're in suggesting inserting the middleware in production.rb That actually would make sense for me since I am using this gem on an application with a staging environment. On October 9, 2016 at 2:59:25 AM, David Somers ([email protected](mailto:[email protected])) wrote:
|
@@ -3,6 +3,16 @@ class LetsencryptRailsHerokuRailtie < Rails::Railtie | |||
Letsencrypt.configure | |||
end | |||
|
|||
initializer "letsencrypt_rails_heroku.configure_rails_initialization" do |app| | |||
if Rails.env.production? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jalada Come to think of it, since you recommend installing this gem in the :production
group, this wouldn't even be required if users heed your recommendation.
Since all we have to do is check for force_ssl I don't see why we can't just do that inside an initialize hook and change the way the middleware is inserted accordingly. Maybe I'm missing something obvious. This would reduce the amount of manual configuration required for this gem.
5e1bb71
to
117ce3f
Compare
@jalada Removed the conditional branch that was checking |
Good point re: installing the gem in the
As an alternative, what about a helper function that could be called in an initialiser (perhaps including a Rails generator to create it) that adds the middleware in this manner, e.g.
# config/initializers/letsencrypt.rb
Letsencrypt.add_middleware! That way, installation is simpler, we take away the need to handle Just a suggestion though; want to get the API right :) |
Not quite sure. I can test this fairly simply though.
I don't know. I honestly value convention over configuration hence the PR. But your initializer alternative isn't bad at all. How does the end-user adjust how the middleware is inserted? As an argument to |
Chris Mar gave me a good example for automatic middleware insertion: https://github.com/plataformatec/devise/blob/88724e10adaf9ffd1d8dbfbaadda2b9d40de756a/lib/devise/rails.rb#L22-L27 Granted Devise is a hefty thing but I feel like requiring manual (or semi-manual) addition of an initializer (note than Devise already has an initializer but it's used for configuration, not boot-time setup) is a bit too much. Your call regardless. :-) |
Since all we have to do is check for
force_ssl
I don't see why we can'tjust do that inside an initialize hook and change the way the middleware
is inserted accordingly.
Maybe I'm missing something obvious. This would reduce the amount of manual
configuration required for this gem.