<p>A similar question was asked in the Craft Slack today, so I thought I'd transcribe the consensus:</p>

<p>Internally, CSRF tokens come from a call to <code>Craft::$app-&gt;getRequest()-&gt;getCsrfToken()</code>. This means that any controller (or template, for that matter—more often handled by the <code>{{ csrfInput() }}</code> shortcut method) can grab a CSRF token at will.</p>

<p>In the original post, I'd noted that the <code>users/get-remaining-session-time</code> action returns a token—that token comes from the above call, so it certainly sounds like a valid built-in method for grabbing tokens.</p>

<p>That said, it does have some potential side effects related to the session (aside from refreshing the CSRF token).</p>

<p>Ultimately—provided the time—it seems like the recommended method is to create a custom controller and call the method explicitly.</p>

<p>As far as the client-side handling… if your application has a means to consolidate AJAX calls, it'd be worth automating the refresh and inclusion of CSRF tokens as HTTP headers. For example, before a regular POST request is initiated, the client might first ensure it has a fresh CSRF token, <em>then</em> issue the request with the new token.</p>

<p>Hope this helps anyone else getting started with client-rendered applications!</p>

<blockquote>
  <p><strong>Edit:</strong> <a href="https://github.com/craftcms/cms/issues/3858" rel="nofollow noreferrer">As of Craft 3.1.13</a>, you get a CSRF token in the JSON response when a user logs in (assuming the login occurs over Ajax)!</p>
</blockquote>

CC BY-SA 4.0
2019-03-05T23:28:43.013Z
Worth noting—correct me if I'm wrong: the token isn't really “consumed”… it actually remains valid for the length of the session. You just happen to get a new one with each template-y request, because that's the expected behavior of the `getCsrfToken` method. So, with the `3.1.13` update, you can just immediately turn around and send this token to your application as many times as you like, without needing to refresh it. Cool!
August Miller
CC BY-SA 4.0
2018-12-12T19:40:08.497Z
2019-02-21T08:06:34.597Z
2019-02-21T08:06:34.597Z
August Miller
<p>There are a number of answers here about how to send CSRF tokens along with AJAX requests, but I think my question is a little different. Please excuse the abstractness here:</p>

<p>In a headless application, I'd like to be able to log users in via AJAX, and keep a fresh CSRF token in the client-side application's state.</p>

<p>Is there a way to get a new token, once one has been consumed?</p>

<p>Imagine a case where a customer adds an item to their cart—that token is consumed, and a new one is issued on the next page load… but what if there <em>isn't</em> a new page load?</p>

<p>Am I even thinking about this the right way?</p>

<hr>

<p><em>In looking at the <code>UsersController</code>, I noticed that the <code>get-remaining-session-time</code> action sends a <code>csrfTokenValue</code>. Any chance this is part of the answer?</em></p>

<craft3><ajax><headless>
CSRF in “Headless” Applications
# CSRF in “Headless” Applications

(Asked by: username_0 on 2018-12-10)

There are a number of answers here about how to send CSRF tokens along with AJAX requests, but I think my question is a little different. Please excuse the abstractness here:

In a headless application, I'd like to be able to log users in via AJAX, and keep a fresh CSRF token in the client-side application's state.

Is there a way to get a new token, once one has been consumed?

Imagine a case where a customer adds an item to their cart—that token is consumed, and a new one is issued on the next page load… but what if there *isn't* a new page load?

Am I even thinking about this the right way?

---

*In looking at the `UsersController`, I noticed that the `get-remaining-session-time` action sends a `csrfTokenValue`. Any chance this is part of the answer?*

**Tags:** craft3, ajax, headless

---

## 1 answers

### Answer by username_0 on 2018-12-12. Score: 4 | Accepted answer

A similar question was asked in the Craft Slack today, so I thought I'd transcribe the consensus:

Internally, CSRF tokens come from a call to `Craft::$app->getRequest()->getCsrfToken()`. This means that any controller (or template, for that matter—more often handled by the `{{ csrfInput() }}` shortcut method) can grab a CSRF token at will.

In the original post, I'd noted that the `users/get-remaining-session-time` action returns a token—that token comes from the above call, so it certainly sounds like a valid built-in method for grabbing tokens.

That said, it does have some potential side effects related to the session (aside from refreshing the CSRF token).

Ultimately—provided the time—it seems like the recommended method is to create a custom controller and call the method explicitly.

As far as the client-side handling… if your application has a means to consolidate AJAX calls, it'd be worth automating the refresh and inclusion of CSRF tokens as HTTP headers. For example, before a regular POST request is initiated, the client might first ensure it has a fresh CSRF token, *then* issue the request with the new token.

Hope this helps anyone else getting started with client-rendered applications!

> **Edit:** [As of Craft 3.1.13](https://github.com/craftcms/cms/issues/3858), you get a CSRF token in the JSON response when a user logs in (assuming the login occurs over Ajax)!

> **Comments:**
> **username_0**: Worth noting—correct me if I'm wrong: the token isn't really “consumed”… it actually remains valid for the length of the session. You just happen to get a new one with each template-y request, because that's the expected behavior of the `getCsrfToken` method. So, with the `3.1.13` update, you can just immediately turn around and send this token to your application as many times as you like, without needing to refresh it. Cool!  

---

