-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Support Rails 4 #2376
Support Rails 4 #2376
Conversation
This was the previous functionality since we didn't set anything in the application configuration. Now when using protected attributes gem, it sets whitelist to true, forcing us to always declare the accessible attributes, and this is not the case for the Admin model.
This is the commit in Rails rails/rails@db06d128
Mass-assignment security roles are removed in Rails 4 so there's no need to test :as => :role behavior.
This brings support for Rails 4 StrongParameters changes. - Parameter sanitizing is setup for Devise controllers via resource_params except Omniauth Callbacks which doesn't use resource_params. - Change #build_resource to not call resource_params for get requests. Parameter sanitizing is only needed when params are posted to the server so there's no need to try to construct resource params on get requests (new, edit).
This way it's very explicit that this method is for devise and it won't run into any naming collisions with user code.
This updates Devise's StrongParameter support to feature: - A Null base sanitizer to support existing Rails 3.x installations that don't want to use StrongParameters yet - A new, simpler API for ParameterSanitizer: #permit, #permit!, and #forbid - Overrideable callbacks on a controller-basis, e.g. #create_sessions_params for passing the current scope's parameters through StrongParameters and a helper method, whitelisted_params, for rolling your own implementations of #create_x_params in your own controllers. - Lots of tests!
There's no encrypted cookie store anymore, by default the cookie store will be encrypted.
I vote for supporting both 3.2 and 4.0. It gives a clear and easy upgrade path with no breaking changes. As a longtime rails and devise user, I know well the challenges of upgrading between rails releases and not having to worry about touching my devise-related code would be a great relief. |
I have no problem with the support to Rails 3.2, but if we are going to do this we need to test it in the travis matrix with ruby 1.9 and ruby 1.8 |
+1 for supporting both 3.2 and 4.0 |
@josevalim could we update the Gemfile for the rails 4.0.0.rc1? #2399 |
There you go, rails4 branch is now green on both 3.2 and 4.0.rc1, with both Active Record and Mongoid (master). Thanks guys for the great work on the parameter sanitize stuff. ✨ 💖 ✨ |
❤️ 💚 💙 💛 💜 |
Plus dropping support for Rails < 3.2 and Ruby < 1.9.3 [ci skip]
I'm merging this to master, lets get this beta out! 🎉 |
Support Rails 4 Keep compatibility with Rails 3.2. Drop support to Ruby 1.8.
|
||
if Devise.rails4? | ||
config.secret_key_base = 'd588e99efff13a86461fd6ab82327823ad2f8feb5dc217ce652cdd9f0dfc5eb4b5a62a92d24d2574d7d51dfb1ea8dd453ea54e00cf672159a13104a135422a10' |
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.
You should consider including secret_token
here to avoid invaliding sessions generated by Rails 3. See the "2.6 Action Pack" section here for details: http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html for details.
I am sending a pull request for the Rails 4 branch, I believe we are almost ready. Thanks guys for all your work!
Giving the changes in the PR, it seems possible to support both Rails 3.2 and Rails 4. Most of the changes are actually in the testing side. What do you guys think? Should we change this pull request to revert support to both?
💟