Add remote-form CSRF token coverage for the 3.2 to 4.0 hop - #130
Open
JuanVqz wants to merge 1 commit into
Open
Conversation
JuanVqz
force-pushed
the
feature/remote-form-csrf-token
branch
from
August 27, 2026 00:38
bda4ee3 to
670dc66
Compare
Rails 4.0 flips embed_authenticity_token_in_remote_forms from true to false, so remote: true forms stop rendering the hidden authenticity_token field. From then on the token reaches the server only as the X-CSRF-Token header UJS sets from the csrf-token meta tag, which means the form is protected only while UJS is the thing submitting it. Any other submit path posts with no CSRF token at all, and a bare protect_from_forgery nulls the session instead of raising, so the request silently loses its user rather than erroring. Rails made the change for fragment caching: the token is per-session, so the hidden field makes the form's HTML unique per user and uncacheable. Remote forms were assumed to always be submitted by UJS as an XHR, which in a real application they are not. Nothing warns and no test catches it. The Rails-side change is the absence of a config line, the failure is browser-only, and allow_forgery_protection is off in the test environment, so the missing field is invisible to the whole suite. - REMOTE_FORM_CSRF_TOKEN in rails-40-patterns.yml, with fixture expectations - section 6 in upgrade-3.2-to-4.0.md (6 through 24 renumbered), carrying the mechanism, why Rails made the change, how to confirm the flip on both boots, the fix, the fetch case, and the regression test that catches it The detail lives in the 4.0 guide rather than a new references/ file or a testing-checklist item: the issue is specific to this hop, references/ is for cross-version material, and the checklist already asks whether remote forms and CSRF protection work. SKILL.md and the CHANGELOG are untouched. Dry-run against a real 3.2 app: the pattern found 8 remote forms.
JuanVqz
force-pushed
the
feature/remote-form-csrf-token
branch
from
August 27, 2026 01:25
670dc66 to
34f168e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rails 4.0 flips
embed_authenticity_token_in_remote_formstofalse, soremote: trueforms stop rendering the hiddenauthenticity_token. The token then only reaches the server as theX-CSRF-Tokenheader UJS sets, so any submit path that bypasses UJS posts with no token. A bareprotect_from_forgerynulls the session instead of raising, so the request silently loses its user.Nothing warns and no test catches it: the Rails-side change is an absent config line, the failure is browser-only, and
allow_forgery_protectionis off in the test environment.