Skip to content
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

Merged
merged 42 commits into from
May 7, 2013
Merged

Support Rails 4 #2376

merged 42 commits into from
May 7, 2013

Conversation

josevalim
Copy link
Contributor

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?

💟

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.
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.
@latortuga
Copy link
Contributor

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.

@rafaelfranca
Copy link
Collaborator

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

@vipulnsward
Copy link
Contributor

+1 for supporting both 3.2 and 4.0

@tonini
Copy link

tonini commented May 3, 2013

@josevalim could we update the Gemfile for the rails 4.0.0.rc1? #2399

@carlosantoniodasilva
Copy link
Member

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.

✨ 💖 ✨

@josevalim
Copy link
Contributor Author

❤️ 💚 💙 💛 💜

Plus dropping support for Rails < 3.2 and Ruby < 1.9.3
[ci skip]
@carlosantoniodasilva
Copy link
Member

I'm merging this to master, lets get this beta out! 🎉

carlosantoniodasilva added a commit that referenced this pull request May 7, 2013
Support Rails 4

Keep compatibility with Rails 3.2. Drop support to Ruby 1.8.
@carlosantoniodasilva carlosantoniodasilva merged commit 270e2ec into master May 7, 2013

if Devise.rails4?
config.secret_key_base = 'd588e99efff13a86461fd6ab82327823ad2f8feb5dc217ce652cdd9f0dfc5eb4b5a62a92d24d2574d7d51dfb1ea8dd453ea54e00cf672159a13104a135422a10'
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.