CMS-1282 Static cache-safe csrfInput()

@timkelty Would it make more sense to return a placeholder <div> with a unique ID where the CSRF input should go, and then register the JS via View::registerJs(), so the Ajax request doesn’t block page rendering?

@timkelty Would it make more sense to return a placeholder <div> with a unique ID where the CSRF input should go, and then register the JS via View::registerJs(), so the Ajax request doesn’t block page rendering?

@brandonkelly for that reason, I don't think so – we can achieve the same thing with aync or defer attributes on the script (check me here @brianjhanson).

However, if we wanted to support multiple forms/csrfs with a single fetch, IDs and View::registerJs() would probably be the way to go.

Blitz's CSRF tags do this, but I thought it was maybe too much for the initial core functionality.

In theory each CSRF input will have the same name and value right? So it might make sense to just set a data-csrf-placeholder attribute on a placeholder div, and have the JS swap out all placeholder instances with the input. At that point the JS code would be identical each time, so it would only get registered once (View::registerJs() ensures uniqueness).

In theory each CSRF input will have the same name and value right? So it might make sense to just set a data-csrf-placeholder attribute on a placeholder div, and have the JS swap out all placeholder instances with the input. At that point the JS code would be identical each time, so it would only get registered once (View::registerJs() ensures uniqueness).

The way it is implemented now, each instance will get a new CSRF…which initially I was thinking was desirable, but I guess there's no reason they couldn't all be the same, right?

The token values will be different each time, but as long as the user session doesn’t change, any of them will work in place of one another. And they can be reused—Craft’s control panel JS will just get a single CSRF token, and reuse it for each Ajax request.

In theory each CSRF input will have the same name and value right? So it might make sense to just set a data-csrf-placeholder attribute on a placeholder div, and have the JS swap out all placeholder instances with the input. At that point the JS code would be identical each time, so it would only get registered once (View::registerJs() ensures uniqueness).

@brandonkelly ok, refactored.

• uses a custom element, <craft-csrf-input> as a placeholder. While it doesn't get registered as a web component (because it doesn't need to), it seems better to use as a placeholder/selector. The craft- prefix follows the web component stuff @brianjhanson has been using.
• I'm using View::registerHtml instead of View::registerJs for a couple reasons:
  • I need to pass the URL as a variable
  • I loathe JS in PHP