CSRF protection when migrating from Rails 3 to Rails 4












0














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.










share|improve this question



























    0














    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.










    share|improve this question

























      0












      0








      0







      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.










      share|improve this question













      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






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Nov 13 '18 at 0:48









      growling_egggrowling_egg

      747




      747
























          2 Answers
          2






          active

          oldest

          votes


















          0














          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






          share|improve this answer

















          • 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 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










          • 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



















          0














          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






          share|improve this answer





















          • 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











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          0














          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






          share|improve this answer

















          • 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 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










          • 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
















          0














          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






          share|improve this answer

















          • 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 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










          • 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














          0












          0








          0






          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






          share|improve this answer












          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







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 13 '18 at 1:53









          Kyle HeironimusKyle Heironimus

          4,68452742




          4,68452742








          • 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 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










          • 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














          • 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 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










          • 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








          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













          0














          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






          share|improve this answer





















          • 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
















          0














          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






          share|improve this answer





















          • 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














          0












          0








          0






          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






          share|improve this answer












          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







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 13 '18 at 10:48









          lacostenycoderlacostenycoder

          3,66311227




          3,66311227












          • 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












          • 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


















          draft saved

          draft discarded




















































          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.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • 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.




          draft saved


          draft discarded














          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





















































          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







          這個網誌中的熱門文章

          Post-Redirect-Get with Spring WebFlux and Thymeleaf

          Xamarin.form Move up view when keyboard appear

          JBPM : POST request for execute process go wrong