Turbo stream partial with button_to tag throws ActionView::Template::Error

[pettersj]

after_create_commit with broadcast_append_to throws this error:
ActionView::Template::Error (Request forgery protection requires a working session store but your application has sessions disabled. You need to either disable request forgery protection, or configure a working session store.)
(seems to happen to all broadcasts with partials)

Log trace:

10:22:02 web.1  | ActionView::Template::Error (Request forgery protection requires a working session store but your application has sessions disabled. You need to either disable request forgery protection, or configure a working session store.):
10:22:02 web.1  |     13:     <div class="flex">
10:22:02 web.1  |     14: 
10:22:02 web.1  |     15:       <div class="up">
10:22:02 web.1  |     16:         <%= button_to increment_question_group_path(question_group), method: :patch do %>
10:22:02 web.1  |     17:           <svg xmlns="http://www.w3.org/2000/svg" class="h-5 w-5 text-gray-500 font-light" viewBox="0 0 20 20" fill="currentColor">
10:22:02 web.1  |     18:             <path fill-rule="evenodd" d="M5.293 9.707a1 1 0 010-1.414l4-4a1 1 0 011.414 0l4 4a1 1 0 01-1.414 1.414L11 7.414V15a1 1 0 11-2 0V7.414L6.707 9.707a1 1 0 01-1.414 0z" clip-rule="evenodd" />
10:22:02 web.1  |     19:           </svg>
10:22:02 web.1  |   
10:22:02 web.1  | app/views/question_groups/_question_group.html.erb:16
10:22:02 web.1  | app/models/question_group.rb:16:in `append_to_list'

Rails 7 alpha2, turbo-rails 0.7.14

[pettersj]

The same is happening with forms that are either post, patch or delete. method: :get works fine.

[dhh]

Are you sure you have a working session store, as the error mentions? Can you create a boiled down app that replicates this? Not seeing it on my end.

[pettersj]

Yeah, the session store is fine. There's something strange going on here, because a it actually does replace with a normal _form.html.erb. I'll close it for now, won't bother you with it, I'm definitely doing something wrong 😅

[DavidColby]

I believe this needs to be reopened.

Rails 7 alpha raises an error when sessions are disabled, which appears to break model broadcasts.

A minimal application reproducing the error can be found here: https://github.com/DavidColby/turbo_rails_7_bug

This app includes an after_create_commit broadcast:

class Post < ApplicationRecord
  after_create_commit -> { broadcast_prepend_to 'posts' }
end

And it includes a button_to in the post partial:

<%= button_to "Destroy this post", post_path(post), method: :delete %>

Note that a form_with will fail too, rendering any form appears to cause the error.

To reproduce on this app, boot up the app, head to /posts/new and see that ActionController::RequestForgeryProtection::DisabledSessionError in Posts#create is raised when you attempt to submit the form.

Uncomment this line and reboot the app and see that post submission works as expected.

[DavidColby]

Looking at this further, it may be more appropriate to raise this issue against Rails since the change to default to raising errors when the session is disabled causes rendering outside of the controller context to fail and turbo-rails isn't the only library that expects to be able to safely render partials from models, background jobs, etc.

I'll leave this here for now and see what others think. IMO, a default in Rails 7 that explicitly breaks rendering from models seems like an incorrect default given the reliance on this pattern in a number of libraries.

[dhh]

cc @byroot

[byroot]

a default in Rails 7 that explicitly breaks rendering from models

It's not really what it's doing. It's a default that ensure that if you view depends on a session store (e..g because it need to store a CSRF token), then that feature ensure it raise loudly rather than letting you generate tokens that will later be rejected because they weren't saved in any session.

So I don't think we should change that default, but we should figure out how to get your rendering context access to the session, or your view to no longer need a session.

I'm away for the next ~48 hours, but I can dig into this when I get back.

Uncomment this line and reboot the app and see that post submission works as expected.

Does the button work too? If the CSRF token wasn't saved in the session, the button shouldn't work. Unless of course you have CSRF protection disabled, in which case the rendering shouldn't generate a token.

[jwilsjustin]

I was able to address this be changing from button_to to link_to since link_to will get a CSRF token on the fly.

[DavidColby]

@jwilsjustin Yeah, swapping the button_to for a link_to sidesteps the issue. It seems like using link_to for delete actions like this is being strongly discouraged for a variety of reasons, but it is an option.

You can also do weirder stuff like wrapping the button/form in a lazy loaded turbo-frame to bypass the error, but... gross.

@byroot I know very little about the internal workings of CSRF or anything else really, so I'll happily defer to your judgement on all of this stuff.

If Rails ships with this as the default behavior, it might at least be worth adding config.action_controller.silence_disabled_session_errors = false into the config with a note explaining what it does to make tracking down the issue a little easier. I was pretty surprised to see a pretty standard piece of Turbo code break in this manner, and the initial report of this issue above seems to indicate some users will struggle with connecting the dots on the resolution to the problem.

Does the button work too? If the CSRF token wasn't saved in the session, the button shouldn't work. Unless of course you have CSRF protection disabled, in which case the rendering shouldn't generate a token.

Yes, the button works as expected, which is surprising to me. To be really sure, I even manually added protect_from_forgery with: :exception into the ApplicationController and the button still works just fine.

I'm on another project today but tonight I will spin up a production app that demonstrates the functionality working with config.action_controller.silence_disabled_session_errors = true. Hopefully that will help with digging in when you (or others) have time to review.

As you said, it seems like it should impossible for a form generated without access to the session to pass CSRF checks, but that doesn't seem to be the case in my testing.

[byroot]

I know very little about the internal workings of CSRF or anything else really,

Conceptually it's not that complicated. When you generate a form, you generate a token, store it in session and add it in an hidden field.

When the form is submitted you compare the token with the one inside the session to ensure they match.

So to generate CSRF protected forms, you need to be able to write in the user session.

it seems like it should impossible for a form generated without access to the session to pass CSRF checks, but that doesn't seem to be the case in my testing.

Yes, that's rather odd, I don't get how it can possibly work. I'll dig into this Wednesday. Maybe the root problem was worked around somehow? (e.g. by generating the CSRF in the main page, not in the snippets, or something along these lines).

If that's the case we'd need to let Action View know that it shouldn't generate a CSRF token in that form.

[DavidColby]

If that's the case we'd need to let Action View know that it shouldn't generate a CSRF token in that form.

It looks like this already happens. Using the example above, when a form is rendered via a broadcast the HTML looks like this:

<form class="button_to" method="post" action="/posts/33">
  <input type="hidden" name="_method" value="delete">
  <button data-confirm="Are you sure?" type="submit">Destroy this post</button>
</form>

The same form rendered during a normal page turn looks like this:

<form class="button_to" method="post" action="/posts/33">
  <input type="hidden" name="_method" value="delete">
  <button data-confirm="Are you sure?" type="submit">Destroy this post</button>
  <input type="hidden" name="authenticity_token" value="somesecuretoken">
</form>

I suppose this means there must be some path that bypasses token generation when the session is unwriteable. Then when the form is submitted without a token, the token from the <head> gets used instead?

[byroot]

Then when the form is submitted without a token, the token from the <head> gets used instead?

That's what I'd expect yes.

[DavidColby]

Some additional info on this, and some thoughts on possible paths forward that don't put folks using Turbo Stream broadcasts, ActionCable broadcasts, or CableReady into a tough spot when they're upgrading.

Users can avoid triggering the error (or deprecation warning) for forms rendered without a session like this:

<%= form_with(model: resource, authenticity_token: false) do |form| %>

button_to does not support the authenticity_token option today but adding support for it should be fairly simple.

If button_to is given the ability to bypass requesting a CSRF token, it should be possible for users to modify their applications to eliminate these errors as part of their upgrade to Rails 7.

Another potential route that avoids the need to ask users to add authenticity_token: false to all of their broadcasted partials might be modifying token_tag to something like this:

def token_tag(token = nil, form_options: {})
  if token != false && defined?(session) && session.enabled? && defined?(protect_against_forgery?) && protect_against_forgery?
    # generate token
  else
     ""
  end
end

session.enabled? is false when rendering outside of the normal controller so we bypass the protect_against_forgery? check which throws the error. In this case, the form still renders fine, the CSRF protection falls back to the token in the head, and all is well.

The latter option of adjusting token_tag feels preferable (if there aren't any potential issues that I'm not able to see) since it should simplify the upgrade path to Rails 7 for users that would otherwise be hit by this change.

This feels like it is pretty far outside the scope of the original report at this point, and I'm happy to open a new issue against Rails to track this if that's preferable.

[byroot]

avoids the need to ask users to add authenticity_token: false to all of their broadcasted partials

I know little of hotwire & al, but yes we should find a solution that doesn't require it.

session.enabled? is false when rendering outside of the normal controller so we bypass the protect_against_forgery?

Ideally we wouldn't rely on session.enabled?, because it would put us back to before rails/rails#42231, which mean users with no session store configured would generate invalid form that would fail CSRF validation later.

What would be best would be to detect wether we're rendering a full page or just a fragment.

[DavidColby]

What would be best would be to detect wether we're rendering a full page or just a fragment.

That would run into problems since it is common to render a partial from a normal controller action, and in those cases users would likely expect their form to generate an authenticity token.

Perhaps something like this, borrowing from request.controller_class to check if the request is originating from a controller?

def controller_request?
  request.present? && request.params["controller"].present?
end

def token_tag(token = nil, form_options: {})
  if token != false && controller_request? && defined?(protect_against_forgery?) && protect_against_forgery?
    token ||= form_authenticity_token(form_options: form_options)
    tag(:input, type: "hidden", name: request_forgery_protection_token.to_s, value: token, autocomplete: "off")
  else
    ""
  end
end

This bails out prior to the session check and seems to resolve the issue locally. I'm unsure if there are other paths that one can take that would result in a request without a controller present that might make this approach problematic.

[seanpdoyle]

I agree, I think this issue needs to be re-opened.

I believe the issue is related to the disparity between how the implementations for form_with, form_for, and button_to handle data-remote attributes and local: options.

The form_with implementation decides on both the presence of [data-remote] and the default behavior when authenticity_token: is omitted:

https://github.com/rails/rails/blob/fb1ab3460a676ce7def0819c2e92289ef2dcbe3b/actionview/lib/action_view/helpers/form_helper.rb#L1564-L1570

The default behavior is to treat a missing local: option as local: config.action_view.form_with_generates_remote_forms.

Alternatively, the button_to implementation does not support a local: option, and instead reads from a remote: option:

https://github.com/rails/rails/blob/fb1ab3460a676ce7def0819c2e92289ef2dcbe3b/actionview/lib/action_view/helpers/url_helper.rb#L325-L343

The button_to implementation completely ignores the config.action_view.form_with_generates_remote_forms setting like form_for, and eagerly generates an authenticity token.

As a short-term, minimal change, I've opened rails/rails#43417 to add support for passing authenticity_token: to button_to calls.

I believe a more broad solution would involve making the Ruby-side changes to continue to deprecate UJS. However, it's unclear to me what the desired behavior should be once support for remote: and local: options is dropped. I've opened rails/rails#43418 to sketch that work out.

It might be worthwhile to introduce a global configuration value that doesn't target a specific form building interface (be it form_with, form_for, or button_to). If full integration with Hotwire is a goal of the UJS deprecation, turbo-rails could set that configuration on the application's behalf from the engine. Does that setting already exist as config.action_controller.per_form_csrf_tokens?

In the short term, could rails/rails#43417 combined with button_to ..., authenticity_token: request.present? checks resolve this issue?

[DavidColby]

@seanpdoyle Thanks for taking the time to look at this in detail!

In the short term, could rails/rails#43417 combined with button_to ..., authenticity_token: request.present? checks resolve this issue?

That change would make it possible to use button_to in stream broadcasts without warnings or errors so it would be a workable short term solution, although it may be painful for applications that are upgrading to Rails 7 with a significant amount of forms to modify.

The default behavior in Rails 6 is for rendering forms like this to work without needing to worry about the authenticity token so I expect even with the button_to change in place, folks will continue to get tripped up on this.

I like the idea of a global config value (perhaps repurposing per_form_csrf_token and applying it to buttons and forms consistently) if adjusting token_tag to bypass the session check when no controller is present isn't a viable path forward.

[seanpdoyle]

@DavidColby I think all of these pieces could fit together in a way that resolves the underlying issue.

Based on the way you've outlined things, I wonder if the token_tag change is the most viable short-term solution, since it's potentially the most back-portable to versions before 7.0.

In the code snippet you've shared about, what is the significance of:

def controller_request?
  request.present? && request.params["controller"].present?
end

Under what circumstances would the return value of request.present? be insufficient to indicate whether or not the render occurs within a request-response cycle?

[DavidColby]

Under what circumstances would the return value of request.present? be insufficient to indicate whether or not the render occurs within a request-response cycle?

I haven't worked through the Rails internals enough so I may be misunderstanding what's happening but I believe that when turbo-rails calls ApplicationController.render, render always builds a new request instance, even outside of the normal request-response cycle.

Running things locally, if I add a binding.break to the rendered view and inspect the value of request during a stream broadcast this is the result:

(rdbg) request
#<ActionDispatch::Request GET "http://example.org" for >

[casperisfine]

What about #256 ?

[casperisfine]

I opened rails/rails#43427 instead. I don't see a good way to identify these cases, so let's get rid of the error/warning for protect_against_forgery.

It will still raise if you try to write to a disabled session directly, so we keep the useful error for all other cases.

[seanpdoyle]

I've tested rails/rails#43427 locally, and it seems to resolve this issue. Thank you both @casperisfine @byroot!

It seems like rails/rails#43417 and rails/rails#43418 aren't necessary for resolving this issue. I'm planning on keeping them open, since they might still be viable in their own right.

[mhenrixon]

I have a related error: ActionController::InvalidAuthenticityToken: Can't verify CSRF token authenticity. I tried adding authenticity_token: true to my button_to but it didn't help. I'm referring to the following PR: rails/rails#43417

[callmarx]

When I was using rails v-7.0.0.alpha2 with turbo-rails v-0.9.0 I solved it with form_with

<%= form_with(model: post, method: :delete, authenticity_token: false) do |form| %>
  <%= form.button :submit, class: "..." do %>
    <svg ...>
    </svg>
  <% end %>
<% end %>

But now, using rails v-7.0.0.rc3 with turbo-rails v-1.0.0 that it is working with button_to and method: :delete

<%= button_to post_path(post), method: :delete,  class: "..." do  %>
   <svg ...>
   </svg>
<% end %>

[mhenrixon]

My solution was a little different:

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  connect() {
    let form = this.element

    if (this.element.type === "submit" || this.element.type === "button") {
      form = this.element.closest("form")
    }

    if (form.querySelector("input[name='authenticity_token']") == null) {
      form.appendChild(this.authenticityToken)
    }
  }

  get authenticityToken() {
    const input = document.createElement("input")

    input.type = "hidden"
    input.name = "authenticity_token"
    input.autocomplete = "off"
    input.value = window.mrujs.csrfToken()

    return input
  }
}

I use mrujs to set an authenticity token dynamically based on the one on the top level.

[tbcooney]

The same is happening with rich_text_field tags used in forms (just to be clear, the form needs to appear in the Turbo broadcast). I found this error in our application to be raised after the changes introduced in rails/rails #38957:
Your application has sessions disabled. To write to the session you must first configure a session store.

after_create_commit with broadcast_append_later_to enqueues a Turbo::Streams::ActionBroadcastJob for the prepend. The newest changes for the rich_text_area_tag helper now checks for a Rails session. The problem with that is a background job won't have a rails session. In our broadcast_append_later_to we send a partial that includes a form and a rich text field.

https://github.com/DmitryTsepelev/rails/blob/193289dbbe146c56ec16faf8dd1a2c88611feb83/actiontext/app/helpers/action_text/tag_helper.rb#L37

Here is an example of the stack trace,

[AhmedNadar]

I have a similar situation like @tbcooney has with <%= form.text_area :body %> ,and to get it wok, I changed to text_area.
I know it is not a perfect solution but It's a temp one.

[aantix]

@tbcooney @AhmedNadar Broadcast from your background job a lazy-loaded turbo frame.

That lazy-loaded frame will then in turn load your form with a second request, using the current user's session.

E.g.

# notes/app/jobs/bookmark_to_note_job.rb
class BookmarkToNoteJob < ApplicationJob
  queue_as :default

  def perform(bookmark)
    ....
    broadcast_prepend_to("#{bookmark.notebook.id}_notes",
                         target: 'notes',
                         partial: 'notes/note_frame',
                         object: bookmark.note,
                         as: :note, locals: { note_active: true })

  end
end

<!-- notes/app/views/notes/_note_frame.html.erb -->
<%= turbo_frame_tag note, src: edit_note_path(note), loading: :lazy do %>
  <!-- The notes/edit form will render here -->
<% end %>

<!-- notes/app/views/notes/edit.html.erb -->
<turbo-frame id="<%= dom_id(@note) %>">
  <%= form_with(model: @note) do |form| %>
    ....
    <%= form.rich_text_area :details %>
  <% end %>
</turbo-frame>

[alhafoudh]

Well, I might be late to the party.
I have this issue and this is my use case which I think is very valid.

When button_to is rendered due to some broadcasts it does not include authenticity_token.

I have button_to inside partial that can be replaced using turbo stream when User updates.
I must use data-turbo="false" for my button_to because the target controller may redirect me to Stripe Customer Portal in some cases which is en external URL.
I cannot use link_to with data-turbo-method="post" because turbo does not support redirecting to external URL's.

Is implementing redirects to external domains using turbo a solution for me?

[kylekeesling]

If you are redirecting outside of your own domain then there is no real benefit to using Turbo, but to your point I don’t believe the API will allow it.

Make sure when you redirect to Stripe Checkout/Portal in your controller use use allow_other_host: true and you should be able to get the job done

https://api.rubyonrails.org/classes/ActionController/Redirecting.html#method-i-redirect_to

[alhafoudh]

If you are redirecting outside of your own domain then there is no real benefit to using Turbo, but to your point I don’t believe the API will allow it.

Make sure when you redirect to Stripe Checkout/Portal in your controller use use allow_other_host: true and you should be able to get the job done

https://api.rubyonrails.org/classes/ActionController/Redirecting.html#method-i-redirect_to

I have allow_other_host: true, but since I redirect to external domain inside turbo navigation the redirect wont happen in browser. It fails because turbo will try to fetch the external url using XHR, not by changing browser window.location.

[kylekeesling]

Correct, which is why the only good solution here is to disable Turbo for this action

[alhafoudh]

Correct, which is why the only good solution here is to disable Turbo for this action

Yes, but then the button_to does not generate authenticity_token When rendered inside turbo broadcast partial. And that is my problem. I get exception about invalid authenticity token. The only solution right now is not disable turbo on that button and also skip authenticity token verification which I dont want.

[mhenrixon]

Yes, but then the button_to does not generate authenticity_token When rendered inside turbo broadcast partial. And that is my problem. I get exception about invalid authenticity token. The only solution right now is not disable turbo on that button and also skip authenticity token verification which I dont want.

My solution with using mrujs to inject the authenticity token as turbo adds it to the DOM is pretty slick @alhafoudh

[alhafoudh]

My solution with using mrujs to inject the authenticity token as turbo adds it to the DOM is pretty slick @alhafoudh

@mhenrixon It might be, but that covers only button_to. There are more cases with this problem.

[Moltenhead]

Hello, just another update on the problem @aantix seems the only solution through turbo atm when triggering the broadcast from a worker. But in the case of displaying a collection that relies on this broadcast you are then forced to setup an n+x situation. So it can be a solution, but you are quickly forced to use another system whenever the n+x is too much of trouble when you can't do without authentication.

[kevinjcoleman]

I was having this same issue and was able to get around it with a pretty simple stimulus controller which I believe could be used with any type of rails form, however I've only used it with button_to.

refresh_authenticity_token_controller.js

import { Controller } from "@hotwired/stimulus";
import Rails from "@rails/ujs";

export default class extends Controller {
  refresh() {
    Rails.refreshCSRFTokens()
  }
}

html.erb usage

<%= button_to "Do something", some_path(model), form: { data: { controller: "refresh-authenticity-token", 
    action: "submit->refresh-authenticity-token#refresh"}}, method: :post %>

[thebravoman]

Stumbled upon this today.
rails (7.0.4)
turbo-rails (1.3.2)

a button_to is used in a partial that is broadcasted. Clicking on it results in "ActionController::InvalidAuthenticityToken (Can't verify CSRF token authenticity.)"

It just seems surprising that it does not work out of the box

[byroot]

We fixed this issue a very long time ago, but we forgot to close the issue.

You must be experiencing something different, would be best to open another issue.

@dhh could you close this issue?

[thebravoman]

Oh, thanks for letting me know. You are probably right. I saw some merger, but as the issue was still open though there is more work to be done. Will see what is causing it on my end.

…

On Wed, 1 Mar 2023, 17:58 Jean Boussier, ***@***.***> wrote: We fixed this issue a very long time ago, but we forgot to close the issue. You must be experiencing something different, would be best to open another issue. @dhh <https://github.com/dhh> could you close this issue? — Reply to this email directly, view it on GitHub <#243 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAGBIOIWOJYW7GBOAY47TWZ5W2BANCNFSM5EQXTQVA> . You are receiving this because you commented.Message ID: ***@***.***>

[asl331]

I had something similar, but I was replacing a view component using brodcast_replace_to, inside the component I had a form_with with a checkbox, and the broadcast was responding to the update action that was triggered through the checkbox, the solution for me was to add in the stimulus controller this.element.querySelector("form").requestSubmit();

import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
switch() {
   this.element.querySelector("form").requestSubmit();
  }
}

[lapser]

Solutions for getting the 'authenticity_token' when a form is rendered via a broadcast from @aantix [1] and @mhenrixon [2] or [2] may work (I'm using the @aantix one, as of now) but IMHO the issue should be handled at a global level.