CSRF protection when migrating from Rails 3 to Rails 4
I am working on migrating a big website package from Ruby 1.9 to Ruby 2.3, and I'm almost done. I've got Rails almost completely moved from 3.2 to 4.2, but I've run into one snag which I cannot figure out, and this project is my first experience with either Ruby or Rails, so I've been picking up the jargon as I go.
When I point my browser to my development server, all my GET requests succeed (200), but all my POST requests fail (500). After some research, I found out about Rails' built-in CSRF protection, and was able to determine that the package I'm working with had this protection in place when it was using Rails 3.2.
With Rails 4.2 in place, the protection seems to be preventing any POST requests from succeeding. After researching it further, I found that Rails 4 encrypts auth cookies before sending them to the web server, whereas Rails 3 did not, and that it's a good practice to use the Rails 3 cookie until all your users are up to Rails 4. I commented out the secret_key_base definition which I'd created as part of the migration and I cleared out my browser cache, so to my understanding, I should now be using the unencrypted Rails 3 cookie.
However, my POST requests still throw 500s. I can't share much code but I've referenced this official guide and I do have this line in my application controller:
protect_from_forgery with: :exception
I've also verified that if I comment out the protection and use:
skip_before_action :verify_authenticity_token
then the POST requests succeed (they are just very insecure).
Most of what I've read seems to indicate that this feature depends on the protect_from_forgery line I showed above, and that's it.
I cannot seem to get these requests to succeed and I wonder if it's just another layer of knowledge I haven't yet picked up. Would very much appreciate any help.
ruby-on-rails ruby ruby-on-rails-3 ruby-on-rails-4
add a comment |
I am working on migrating a big website package from Ruby 1.9 to Ruby 2.3, and I'm almost done. I've got Rails almost completely moved from 3.2 to 4.2, but I've run into one snag which I cannot figure out, and this project is my first experience with either Ruby or Rails, so I've been picking up the jargon as I go.
When I point my browser to my development server, all my GET requests succeed (200), but all my POST requests fail (500). After some research, I found out about Rails' built-in CSRF protection, and was able to determine that the package I'm working with had this protection in place when it was using Rails 3.2.
With Rails 4.2 in place, the protection seems to be preventing any POST requests from succeeding. After researching it further, I found that Rails 4 encrypts auth cookies before sending them to the web server, whereas Rails 3 did not, and that it's a good practice to use the Rails 3 cookie until all your users are up to Rails 4. I commented out the secret_key_base definition which I'd created as part of the migration and I cleared out my browser cache, so to my understanding, I should now be using the unencrypted Rails 3 cookie.
However, my POST requests still throw 500s. I can't share much code but I've referenced this official guide and I do have this line in my application controller:
protect_from_forgery with: :exception
I've also verified that if I comment out the protection and use:
skip_before_action :verify_authenticity_token
then the POST requests succeed (they are just very insecure).
Most of what I've read seems to indicate that this feature depends on the protect_from_forgery line I showed above, and that's it.
I cannot seem to get these requests to succeed and I wonder if it's just another layer of knowledge I haven't yet picked up. Would very much appreciate any help.
ruby-on-rails ruby ruby-on-rails-3 ruby-on-rails-4
add a comment |
I am working on migrating a big website package from Ruby 1.9 to Ruby 2.3, and I'm almost done. I've got Rails almost completely moved from 3.2 to 4.2, but I've run into one snag which I cannot figure out, and this project is my first experience with either Ruby or Rails, so I've been picking up the jargon as I go.
When I point my browser to my development server, all my GET requests succeed (200), but all my POST requests fail (500). After some research, I found out about Rails' built-in CSRF protection, and was able to determine that the package I'm working with had this protection in place when it was using Rails 3.2.
With Rails 4.2 in place, the protection seems to be preventing any POST requests from succeeding. After researching it further, I found that Rails 4 encrypts auth cookies before sending them to the web server, whereas Rails 3 did not, and that it's a good practice to use the Rails 3 cookie until all your users are up to Rails 4. I commented out the secret_key_base definition which I'd created as part of the migration and I cleared out my browser cache, so to my understanding, I should now be using the unencrypted Rails 3 cookie.
However, my POST requests still throw 500s. I can't share much code but I've referenced this official guide and I do have this line in my application controller:
protect_from_forgery with: :exception
I've also verified that if I comment out the protection and use:
skip_before_action :verify_authenticity_token
then the POST requests succeed (they are just very insecure).
Most of what I've read seems to indicate that this feature depends on the protect_from_forgery line I showed above, and that's it.
I cannot seem to get these requests to succeed and I wonder if it's just another layer of knowledge I haven't yet picked up. Would very much appreciate any help.
ruby-on-rails ruby ruby-on-rails-3 ruby-on-rails-4
I am working on migrating a big website package from Ruby 1.9 to Ruby 2.3, and I'm almost done. I've got Rails almost completely moved from 3.2 to 4.2, but I've run into one snag which I cannot figure out, and this project is my first experience with either Ruby or Rails, so I've been picking up the jargon as I go.
When I point my browser to my development server, all my GET requests succeed (200), but all my POST requests fail (500). After some research, I found out about Rails' built-in CSRF protection, and was able to determine that the package I'm working with had this protection in place when it was using Rails 3.2.
With Rails 4.2 in place, the protection seems to be preventing any POST requests from succeeding. After researching it further, I found that Rails 4 encrypts auth cookies before sending them to the web server, whereas Rails 3 did not, and that it's a good practice to use the Rails 3 cookie until all your users are up to Rails 4. I commented out the secret_key_base definition which I'd created as part of the migration and I cleared out my browser cache, so to my understanding, I should now be using the unencrypted Rails 3 cookie.
However, my POST requests still throw 500s. I can't share much code but I've referenced this official guide and I do have this line in my application controller:
protect_from_forgery with: :exception
I've also verified that if I comment out the protection and use:
skip_before_action :verify_authenticity_token
then the POST requests succeed (they are just very insecure).
Most of what I've read seems to indicate that this feature depends on the protect_from_forgery line I showed above, and that's it.
I cannot seem to get these requests to succeed and I wonder if it's just another layer of knowledge I haven't yet picked up. Would very much appreciate any help.
ruby-on-rails ruby ruby-on-rails-3 ruby-on-rails-4
ruby-on-rails ruby ruby-on-rails-3 ruby-on-rails-4
asked Nov 13 '18 at 0:48
growling_egggrowling_egg
747
747
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Your application layout, probably app/views/layouts/applications.html.erb
needs to refer to <%= csrf_meta_tags %>
This is what is included and checked in all form posts.
If you are not using that layout in all your views, you need to figure out another way to make sure it gets referenced everywhere.
Docs
2
In that directory I don't have any .erb files but I do have application.haml, which starts with: %html %head = csrf_meta_tags My assumption is this serves the same purpose but via a different markup language?
– growling_egg
Nov 13 '18 at 2:26
1
yes, this means you are usinghaml
instead oferb
and it should not have any effect on the error
– Deepak Mahakale
Nov 13 '18 at 4:56
Hi, thanks for the comment. To clarify, do you mean that if I use haml that it will not enable csrf protection correctly? Or do you mean that I can use either one and it should work? In the second case, is there any other reason for these POST requests to fail? Thanks!
– growling_egg
Nov 13 '18 at 6:38
I guess one other question, does putting this meta tag under %head in the application.haml file make it so that it can get referenced everywhere? Or am I only applying this to a subset of my package? Seems to me this setting would apply globally but wanted to double check. In which case, why is this issue still occurring?
– growling_egg
Nov 13 '18 at 7:10
It appears that this is not your problem, so I would look elsewhere, possibly to theconfig/secrets.yml
file mentioned in another answer.
– Kyle Heironimus
Nov 13 '18 at 13:41
add a comment |
Do you have a config/secrets.yml
file ? It should look something like this:
development:
secret_key_base: a75d...
test:
secret_key_base: 492f...
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
And if so you need to make sure your server has the environment variable set. Keys need to be handled carefully and NEVER committed to a public repo i.e. GIT.
Refer to https://guides.rubyonrails.org/v4.2/security.html
Sorry posted too early. Will update when I have enough info.
– growling_egg
Nov 13 '18 at 16:33
Ok so I have a question about this. In the logs for my web server, I saw this warning: Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.
– growling_egg
Nov 13 '18 at 17:14
I take this to mean that until we've rolled out this upgrade to our whole user base and we've verified that there aren't any issues, we need to comment out the secret_key_base lines in the secret_token.rb and keep using the secret_token definition. Does this mean that in my secrets.yml file, I should use: development: secret_token instead?
– growling_egg
Nov 13 '18 at 17:16
Tried replacing references to secret_key_base in secrets.yml with secret_token, still getting failed POSTs (500).
– growling_egg
Nov 13 '18 at 17:34
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53272194%2fcsrf-protection-when-migrating-from-rails-3-to-rails-4%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your application layout, probably app/views/layouts/applications.html.erb
needs to refer to <%= csrf_meta_tags %>
This is what is included and checked in all form posts.
If you are not using that layout in all your views, you need to figure out another way to make sure it gets referenced everywhere.
Docs
2
In that directory I don't have any .erb files but I do have application.haml, which starts with: %html %head = csrf_meta_tags My assumption is this serves the same purpose but via a different markup language?
– growling_egg
Nov 13 '18 at 2:26
1
yes, this means you are usinghaml
instead oferb
and it should not have any effect on the error
– Deepak Mahakale
Nov 13 '18 at 4:56
Hi, thanks for the comment. To clarify, do you mean that if I use haml that it will not enable csrf protection correctly? Or do you mean that I can use either one and it should work? In the second case, is there any other reason for these POST requests to fail? Thanks!
– growling_egg
Nov 13 '18 at 6:38
I guess one other question, does putting this meta tag under %head in the application.haml file make it so that it can get referenced everywhere? Or am I only applying this to a subset of my package? Seems to me this setting would apply globally but wanted to double check. In which case, why is this issue still occurring?
– growling_egg
Nov 13 '18 at 7:10
It appears that this is not your problem, so I would look elsewhere, possibly to theconfig/secrets.yml
file mentioned in another answer.
– Kyle Heironimus
Nov 13 '18 at 13:41
add a comment |
Your application layout, probably app/views/layouts/applications.html.erb
needs to refer to <%= csrf_meta_tags %>
This is what is included and checked in all form posts.
If you are not using that layout in all your views, you need to figure out another way to make sure it gets referenced everywhere.
Docs
2
In that directory I don't have any .erb files but I do have application.haml, which starts with: %html %head = csrf_meta_tags My assumption is this serves the same purpose but via a different markup language?
– growling_egg
Nov 13 '18 at 2:26
1
yes, this means you are usinghaml
instead oferb
and it should not have any effect on the error
– Deepak Mahakale
Nov 13 '18 at 4:56
Hi, thanks for the comment. To clarify, do you mean that if I use haml that it will not enable csrf protection correctly? Or do you mean that I can use either one and it should work? In the second case, is there any other reason for these POST requests to fail? Thanks!
– growling_egg
Nov 13 '18 at 6:38
I guess one other question, does putting this meta tag under %head in the application.haml file make it so that it can get referenced everywhere? Or am I only applying this to a subset of my package? Seems to me this setting would apply globally but wanted to double check. In which case, why is this issue still occurring?
– growling_egg
Nov 13 '18 at 7:10
It appears that this is not your problem, so I would look elsewhere, possibly to theconfig/secrets.yml
file mentioned in another answer.
– Kyle Heironimus
Nov 13 '18 at 13:41
add a comment |
Your application layout, probably app/views/layouts/applications.html.erb
needs to refer to <%= csrf_meta_tags %>
This is what is included and checked in all form posts.
If you are not using that layout in all your views, you need to figure out another way to make sure it gets referenced everywhere.
Docs
Your application layout, probably app/views/layouts/applications.html.erb
needs to refer to <%= csrf_meta_tags %>
This is what is included and checked in all form posts.
If you are not using that layout in all your views, you need to figure out another way to make sure it gets referenced everywhere.
Docs
answered Nov 13 '18 at 1:53
Kyle HeironimusKyle Heironimus
4,69952742
4,69952742
2
In that directory I don't have any .erb files but I do have application.haml, which starts with: %html %head = csrf_meta_tags My assumption is this serves the same purpose but via a different markup language?
– growling_egg
Nov 13 '18 at 2:26
1
yes, this means you are usinghaml
instead oferb
and it should not have any effect on the error
– Deepak Mahakale
Nov 13 '18 at 4:56
Hi, thanks for the comment. To clarify, do you mean that if I use haml that it will not enable csrf protection correctly? Or do you mean that I can use either one and it should work? In the second case, is there any other reason for these POST requests to fail? Thanks!
– growling_egg
Nov 13 '18 at 6:38
I guess one other question, does putting this meta tag under %head in the application.haml file make it so that it can get referenced everywhere? Or am I only applying this to a subset of my package? Seems to me this setting would apply globally but wanted to double check. In which case, why is this issue still occurring?
– growling_egg
Nov 13 '18 at 7:10
It appears that this is not your problem, so I would look elsewhere, possibly to theconfig/secrets.yml
file mentioned in another answer.
– Kyle Heironimus
Nov 13 '18 at 13:41
add a comment |
2
In that directory I don't have any .erb files but I do have application.haml, which starts with: %html %head = csrf_meta_tags My assumption is this serves the same purpose but via a different markup language?
– growling_egg
Nov 13 '18 at 2:26
1
yes, this means you are usinghaml
instead oferb
and it should not have any effect on the error
– Deepak Mahakale
Nov 13 '18 at 4:56
Hi, thanks for the comment. To clarify, do you mean that if I use haml that it will not enable csrf protection correctly? Or do you mean that I can use either one and it should work? In the second case, is there any other reason for these POST requests to fail? Thanks!
– growling_egg
Nov 13 '18 at 6:38
I guess one other question, does putting this meta tag under %head in the application.haml file make it so that it can get referenced everywhere? Or am I only applying this to a subset of my package? Seems to me this setting would apply globally but wanted to double check. In which case, why is this issue still occurring?
– growling_egg
Nov 13 '18 at 7:10
It appears that this is not your problem, so I would look elsewhere, possibly to theconfig/secrets.yml
file mentioned in another answer.
– Kyle Heironimus
Nov 13 '18 at 13:41
2
2
In that directory I don't have any .erb files but I do have application.haml, which starts with: %html %head = csrf_meta_tags My assumption is this serves the same purpose but via a different markup language?
– growling_egg
Nov 13 '18 at 2:26
In that directory I don't have any .erb files but I do have application.haml, which starts with: %html %head = csrf_meta_tags My assumption is this serves the same purpose but via a different markup language?
– growling_egg
Nov 13 '18 at 2:26
1
1
yes, this means you are using
haml
instead of erb
and it should not have any effect on the error– Deepak Mahakale
Nov 13 '18 at 4:56
yes, this means you are using
haml
instead of erb
and it should not have any effect on the error– Deepak Mahakale
Nov 13 '18 at 4:56
Hi, thanks for the comment. To clarify, do you mean that if I use haml that it will not enable csrf protection correctly? Or do you mean that I can use either one and it should work? In the second case, is there any other reason for these POST requests to fail? Thanks!
– growling_egg
Nov 13 '18 at 6:38
Hi, thanks for the comment. To clarify, do you mean that if I use haml that it will not enable csrf protection correctly? Or do you mean that I can use either one and it should work? In the second case, is there any other reason for these POST requests to fail? Thanks!
– growling_egg
Nov 13 '18 at 6:38
I guess one other question, does putting this meta tag under %head in the application.haml file make it so that it can get referenced everywhere? Or am I only applying this to a subset of my package? Seems to me this setting would apply globally but wanted to double check. In which case, why is this issue still occurring?
– growling_egg
Nov 13 '18 at 7:10
I guess one other question, does putting this meta tag under %head in the application.haml file make it so that it can get referenced everywhere? Or am I only applying this to a subset of my package? Seems to me this setting would apply globally but wanted to double check. In which case, why is this issue still occurring?
– growling_egg
Nov 13 '18 at 7:10
It appears that this is not your problem, so I would look elsewhere, possibly to the
config/secrets.yml
file mentioned in another answer.– Kyle Heironimus
Nov 13 '18 at 13:41
It appears that this is not your problem, so I would look elsewhere, possibly to the
config/secrets.yml
file mentioned in another answer.– Kyle Heironimus
Nov 13 '18 at 13:41
add a comment |
Do you have a config/secrets.yml
file ? It should look something like this:
development:
secret_key_base: a75d...
test:
secret_key_base: 492f...
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
And if so you need to make sure your server has the environment variable set. Keys need to be handled carefully and NEVER committed to a public repo i.e. GIT.
Refer to https://guides.rubyonrails.org/v4.2/security.html
Sorry posted too early. Will update when I have enough info.
– growling_egg
Nov 13 '18 at 16:33
Ok so I have a question about this. In the logs for my web server, I saw this warning: Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.
– growling_egg
Nov 13 '18 at 17:14
I take this to mean that until we've rolled out this upgrade to our whole user base and we've verified that there aren't any issues, we need to comment out the secret_key_base lines in the secret_token.rb and keep using the secret_token definition. Does this mean that in my secrets.yml file, I should use: development: secret_token instead?
– growling_egg
Nov 13 '18 at 17:16
Tried replacing references to secret_key_base in secrets.yml with secret_token, still getting failed POSTs (500).
– growling_egg
Nov 13 '18 at 17:34
add a comment |
Do you have a config/secrets.yml
file ? It should look something like this:
development:
secret_key_base: a75d...
test:
secret_key_base: 492f...
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
And if so you need to make sure your server has the environment variable set. Keys need to be handled carefully and NEVER committed to a public repo i.e. GIT.
Refer to https://guides.rubyonrails.org/v4.2/security.html
Sorry posted too early. Will update when I have enough info.
– growling_egg
Nov 13 '18 at 16:33
Ok so I have a question about this. In the logs for my web server, I saw this warning: Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.
– growling_egg
Nov 13 '18 at 17:14
I take this to mean that until we've rolled out this upgrade to our whole user base and we've verified that there aren't any issues, we need to comment out the secret_key_base lines in the secret_token.rb and keep using the secret_token definition. Does this mean that in my secrets.yml file, I should use: development: secret_token instead?
– growling_egg
Nov 13 '18 at 17:16
Tried replacing references to secret_key_base in secrets.yml with secret_token, still getting failed POSTs (500).
– growling_egg
Nov 13 '18 at 17:34
add a comment |
Do you have a config/secrets.yml
file ? It should look something like this:
development:
secret_key_base: a75d...
test:
secret_key_base: 492f...
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
And if so you need to make sure your server has the environment variable set. Keys need to be handled carefully and NEVER committed to a public repo i.e. GIT.
Refer to https://guides.rubyonrails.org/v4.2/security.html
Do you have a config/secrets.yml
file ? It should look something like this:
development:
secret_key_base: a75d...
test:
secret_key_base: 492f...
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
And if so you need to make sure your server has the environment variable set. Keys need to be handled carefully and NEVER committed to a public repo i.e. GIT.
Refer to https://guides.rubyonrails.org/v4.2/security.html
answered Nov 13 '18 at 10:48
lacostenycoderlacostenycoder
3,68211228
3,68211228
Sorry posted too early. Will update when I have enough info.
– growling_egg
Nov 13 '18 at 16:33
Ok so I have a question about this. In the logs for my web server, I saw this warning: Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.
– growling_egg
Nov 13 '18 at 17:14
I take this to mean that until we've rolled out this upgrade to our whole user base and we've verified that there aren't any issues, we need to comment out the secret_key_base lines in the secret_token.rb and keep using the secret_token definition. Does this mean that in my secrets.yml file, I should use: development: secret_token instead?
– growling_egg
Nov 13 '18 at 17:16
Tried replacing references to secret_key_base in secrets.yml with secret_token, still getting failed POSTs (500).
– growling_egg
Nov 13 '18 at 17:34
add a comment |
Sorry posted too early. Will update when I have enough info.
– growling_egg
Nov 13 '18 at 16:33
Ok so I have a question about this. In the logs for my web server, I saw this warning: Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.
– growling_egg
Nov 13 '18 at 17:14
I take this to mean that until we've rolled out this upgrade to our whole user base and we've verified that there aren't any issues, we need to comment out the secret_key_base lines in the secret_token.rb and keep using the secret_token definition. Does this mean that in my secrets.yml file, I should use: development: secret_token instead?
– growling_egg
Nov 13 '18 at 17:16
Tried replacing references to secret_key_base in secrets.yml with secret_token, still getting failed POSTs (500).
– growling_egg
Nov 13 '18 at 17:34
Sorry posted too early. Will update when I have enough info.
– growling_egg
Nov 13 '18 at 16:33
Sorry posted too early. Will update when I have enough info.
– growling_egg
Nov 13 '18 at 16:33
Ok so I have a question about this. In the logs for my web server, I saw this warning: Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.
– growling_egg
Nov 13 '18 at 17:14
Ok so I have a question about this. In the logs for my web server, I saw this warning: Please note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4.x and are reasonably sure you will not need to rollback to Rails 3.x. This is because cookies signed based on the new secret_key_base in Rails 4.x are not backwards compatible with Rails 3.x. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete.
– growling_egg
Nov 13 '18 at 17:14
I take this to mean that until we've rolled out this upgrade to our whole user base and we've verified that there aren't any issues, we need to comment out the secret_key_base lines in the secret_token.rb and keep using the secret_token definition. Does this mean that in my secrets.yml file, I should use: development: secret_token instead?
– growling_egg
Nov 13 '18 at 17:16
I take this to mean that until we've rolled out this upgrade to our whole user base and we've verified that there aren't any issues, we need to comment out the secret_key_base lines in the secret_token.rb and keep using the secret_token definition. Does this mean that in my secrets.yml file, I should use: development: secret_token instead?
– growling_egg
Nov 13 '18 at 17:16
Tried replacing references to secret_key_base in secrets.yml with secret_token, still getting failed POSTs (500).
– growling_egg
Nov 13 '18 at 17:34
Tried replacing references to secret_key_base in secrets.yml with secret_token, still getting failed POSTs (500).
– growling_egg
Nov 13 '18 at 17:34
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53272194%2fcsrf-protection-when-migrating-from-rails-3-to-rails-4%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown