Wheels.InvalidAuthenticityToken error and prevention

[cfcoder]

I had this buried in another thread and decided it should be it's own thread.
I have a buttonTo() for a button that is to log out the user. I specify the route name "/logout" and the method "DELETE". This renders a form tag with method POST to /logout action. Inside the form tag wrapper is a hidden input for _method DELETE and a button tag for the logout.

In the Sessions controller is a logout action method. The /logout route maps to sessions.logout. So all is wired as it should be, AFAIK. When clicking the button in the app, it throws an error:

After some searching the internet I came upon brief mention about cross-site request forgery csrf projection. I then tried to find directions how to configure an app to provide the protection. I could only find a brief 5 step list of what to do. First 2 steps were pretty straight forward. but steps 3-5 were not so clear. No examples were given to understand and learn from. Here is the article that references the problem I believe I'm encountering:
https://groups.google.com/g/cfwheels/c/m8E3MKUz7A8

Here is the brief list of 5 steps:
https://guides.cfwheels.org/cfwheels-guides/introduction/upgrading#cross-site-request-forgery-csrf-protection

Can someone please help me understand how to do steps 3-5?
Step 3: How do you do it? Example would be helpful.
Step 4: What is meant by updating route definitions?
Step 5. In my example above, my buttonTo is setting the route and method to delete. So What is Step 5 wanting done?

[cfcoder]

I think I've stumbled onto the solution for this problem, at least in my situation. After I did the following, the error went away:

• Made sure the controllers involved with the logout all had a config function. Some didn't.
• Within that config function should include super.config(); as the first call in that function. This assumes you've already put a config function in the /controller/Controller.cfc AND that it contains a call to: protectsFromForgery();

Example config function in a controller other than THE Controller.cfc:

function config(){
	super.config();
}

I still would like to hear responses to Steps 3-5 with examples above.

[neokoenig]

Configure any AJAX calls that POST data to your application to pass the authenticityToken from the tags generated by csrfMetaTags() as an X-CSRF-TOKEN HTTP header.

Essentially any page which has the CSRF meta tags and is doing a "normal" form submission (i.e NOT via javascript) should be covered. What this is referring to is form submissions done via Javascript, as they will not include the <meta> CSRF values, and that you need to add them as a header instead.

The actual implementation depends on your JS library

Here's a simple jQuery example:

$(document).ready(function() {
    $('#myForm').submit(function(event) {
        event.preventDefault();  
        var formData = $(this).serialize(); 
       var token = $('meta[name="csrf-token"]').attr('content');

        $.ajax({
            url: '/submit-form', 
            type: 'POST',
            data: formData,
            headers: {
                'X-CSRF-TOKEN': token
            },
            success: function(response) {
                console.log('Form submitted successfully!'); 
            },
            error: function(xhr, status, error) {
                console.error('Form submission failed:', error); 
            }
        });
    });
});

In most JS libraries, you'd probably end up adding the looking at adding that header automatically (i.e when you configure axios or something, you'd have a default config which would automatically pull in that token if it exists).

Update your route definitions to enforce HTTP verbs on actions that manipulate data (get, post, patch, delete, etc.)

I think this was probably left in from the upgrade instructions from 1.x -> 2.x; the routing in 1.x was all GET or POST. So all it's saying is to use the proper verbs where appropriate.

Make sure that forms within the application are POSTing data to the actions that require post, patch, and delete verbs.

And this is just a reference to that normal forms aren't capable of PUT / PATCH / DELETE, hence the hidden _method attribute which then switches the verb to work with those HTTP verbs. Those (non javascript) forms will just use POST.