-
Notifications
You must be signed in to change notification settings - Fork 21.8k
Set Rails 7.0 cookies_serializer default value to :hybrid #45127
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
Conversation
Hey, thanks for the report. Really sorry to hear this caused problems for you. I guess I'm responsible for that. I think there's two issues here. One is around the cookies serializer default. The other is around the upgrade guide. Cookies serializer default
Yeah, kind of. More specifically you should:
The Can you confirm if you had set a I've had a go at making the explanation for this more clear #45137 Upgrade guide
What this is saying is that you don't need to uncomment all the defaults in the same deployment. eg. you could flip What you should do is:
Does this make sense? I think we could certainly make this more clear on the guide. btw, reasons splitting over multiple deploys (as opposed to multiple commits) is necessary:
|
rails#45127 pointed out that the wording around how to update your `cookies_serializer` safely wasn't clear enough. This PR makes the wording a bit more stern.
Hey Alex, thank you for your detailed response 🙏
Okay yeah, I wasn't sure from the So having that intermediate config loaded in production would've helped indeed. But, actually I think it might have hidden a deeper problem because:
And that would've been a whole lot harder to track down.
The problem is that by moving from the So even though it's optional, it's being done implicitly in the background when doing that step of the upgrade process.
I can confirm we did not have one previously. So we were most likely using the default
Thanks, your explanation makes sense 👍 And I did understand most of that. But I also thought at the time that it wasn't discouraged to go straight to If that's indeed what we want to do, because I do get the sense that So, to summarize my argument for still supporting this change:
Thanks for your time and for considering this 🙏 PS: I'm sorry if I pinged a hundred people on this PR, I thought I should maybe change the base branch to |
Yeah that's correct. That's why in #45137 I make the warning around this a bit more stern. It's safer to just use
I think it's a fair point. I think the general vibe is to not change defaults once they are live, but we could change it again in 7.1. That said I'm not on the core team, and wouldn't mind getting a second opinion from someone with more experience on this as it is a fairly complex issue. (I think we might have more luck with that post-railsconf - I'll follow up next week if necessary.) |
Ah right, I forgot to mention that in my last message, my thought on this was:
Hopefully that would give existing applications enough time under |
Hey @nbcraft, sorry this broke you sessions. Brakeman has been recommending using the
|
This only works if you set the |
Ah yes, it wouldn't work before you added it to the framework defaults 👍 . |
I didn't know about it, thank you, I'll give it a go 👍
Yeah we started our app with Rails I don't know if that was the default state of a Rails 6.0 app, or if something about cookies was done on purpose on our end, but I would think it's the default state because there's really nothing else in that commit, pretty bare-bone project initialization. Also I ran So yeah it appears that we simply went ahead with the default config for Rails 6, which is set to (As mentioned before we do go through the |
:hybrid si the value set for cookies_serializer in new_framework_defaults_7_0.rb.tt These two values should match, so that when removing new_framework_defaults_7_0 and setting config.load_defaults 7.0, we have the same behavior.
57e40fe
to
a3e99c0
Compare
@guilleiguaran Any thoughts on this one (since you merged #45137) ? Thank you 🙏 |
Would it be possible to rescue |
That's a good additional fix as well 👍 It would still break existing sessions when moving over to |
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.
We should not change the default to hybrid. New applications should be using json. If I got the problem, it happened because people thought the config inside the 7_0_defaults
file could be deleted with all the configs and just swapping to load_defaults 7.0
would give the same behavior.
I think the right fix for this is to make clear in that file that hybrid
isn't the 7.0 default and it should be kept as hybrid
unless the application is ok with swapping to json.
Reading the comment, it seems we can clarify that if you want to keep hybrid, you need this config to a different file.
|
Should we also update https://github.com/rails/rails/blob/main/guides/source/upgrading_ruby_on_rails.md#configure-framework-defaults to reflect this? It's advised you to remove the file since the section was added in #33685. |
I mean, you should delete the file, but not before reading its content and making sure you are using the configs you want your application to be using. |
The doc says: In this case, if you app is not using |
Ahh, I see what you mean. I'm guessing when @nbcraft read this they interpreted "new defaults" as meaning whatever is in the file ( Made another docs PR to hopefully clarify further: #45172 |
(Thanks everyone for having a look into this 🙏 )
The problem is the default value put in |
Then But most people will instantly break with |
I did read the file, and expected This was the description then btw:
Which is not the same as: "Going to @ghiculescu made the new version better though 👍 :
I still feel the proposed value (last line above) should reflect the value from The whole point of this file is to progressively check the new defaults will work properly before committing to |
This PR incorporates @p8's feedback on rails#45137 and @rafaelfranca's on rails#45127 (comment)
Looks good to me 👍 |
Though this is still a worthwhile consideration I'd say:
|
@nbcraft I think that would be a good change, yes. Do you want to work on it? |
I might if I can find the time. But if somebody else gets to it first, please mention it here 🙏 EDIT:
|
Without this change if action_dispatch.cookies_serializer is set to json and the app tries to read a marshal-serialized cookie, it will raise a JSON::ParserError which won't clear the cookie and force app users to manually clear the cookie in their browser. (See rails#45127 for original bug discussion)
This should us then allow to switch to :json later on, for example when moving to Rails 7. See rails/rails#45127 and rails/rails#45956 for background information about the serializer and possible issues with it.
Proposing this change as a discussion medium after I experienced troubles upgrading to Rails 7.
Summary
:hybrid
is the value set forcookies_serializer
innew_framework_defaults_7_0.rb.tt
.This and the value in
railties/lib/rails/application/configuration.rb
should match, so that when removingnew_framework_defaults_7_0.rb
and settingconfig.load_defaults 7.0
in one's application config, we still have the same behaviour.if we don't want to change
railties/lib/rails/application/configuration.rb
, maybe the value innew_framework_defaults_7_0.rb.tt
should be changed to:json
instead, but then suggest (in the documentation) to set it to:hybrid
manually in the project'sconfig/application.rb
file instead.Context for this change:
When upgrading my app to Rails 7, I followed the guide, and:
new_framework_defaults_7_0.rb
and added acookie_rotator
initializer, while keepingconfig.load_defaults 6.1
.new_framework_defaults_7_0.rb
and setconfig.load_defaults 7.0
(which I assumed would have the same behaviour as the above).cookies_serializer
value from:hybrid
to:json
, which was not backward compatible.Question:
Was I meant to:
config.load_defaults 6.1
and all values enabled innew_framework_defaults_7_0.rb
new_framework_defaults_7_0.rb
and setconfig.load_defaults 7.0
?Or was it okay to see that my application was running fine locally in the first state (all values enabled in
new_framework_defaults_7_0.rb
) and assume I could replace that byconfig.load_defaults 7.0
and go straight for that instead.If I was meant to do the two deploys, maybe the upgrade guide should specifically mention that instead of this:
Which to me made it sound like it wasn't a requirement.