2

When logging in via a POST to user/login?_format=json I'm sent back a response that looks like this

{
    "current_user": {
        "uid": "233",
        "name": "test"
    },
    "csrf_token": "XXXXXR5HQwidW7CKIDL52tOg4JGKi7Pa-j87KKlr8Mg",
    "logout_token": "XXXX-G35feFznaapSggzlUQEhYKXqom6yYVDwCH5Zxc"
}

I'm also sent back a session cookie that looks like this

name: SESS95f37088bf4f23c4304d24270b7xxxxx

value: rqAupOwS2ieqwClBkwEaWj8-ywLqnQEcAL2xOG-xxxx

When I send a GET to session/token

I receive a seperate token that looks like this _XXXXXnX8k_prCNfdrHp6XeHOUx7DcuouqiLKBBn-Go

I understand that the logout token is used with /user/logout in order remove the cookie and log the user out.

My questions are as follows.

The Cross Site Request Forgery token doesn't seem to be required by any of my end points by default. Is this something I should have the backend require them on specific paths using _csrf_token: 'TRUE' (and be passing with each request using the X-XSRF-TOKEN header?) Is this automatically passed with the cookie by chance?

The same question goes for the session token from session/token should this be being passed with each request, or in general what is the purpose for this token? I've seen this token referenced in docs as another CSRF token. If this is the case why is it different than the one provided by the login POST?

1 Answer 1

3

You are logging in correctly by POSTing the username and password. After you've logged in, a Drupal session is created.

The csrf_token can be used to authorise future requests requests by sending it as a header:

X-CSRF-Token: XXXXXR5HQwidW7CKIDL52tOg4JGKi7Pa-j87KKlr8Mg

You can send this instead of a cookie if you've configured the backend to allow it. I've only used the CORS contrib module as CORS in Drupal core doesn't have the same flexibility.

I understand that the logout token is used with /user/logout in order remove the cookie and log the user out.

Correct.

Also see my answer here: https://drupal.stackexchange.com/a/235712/34673

4
  • You said instead of a cookie. Just confirming you wouldn't ever need to send both the X-CSRF-Token and the cookie? Is one considered more secure? Aug 16, 2018 at 1:25
  • You can use either the header or the cookie, you don't need both. Each would be pretty secure I imagine, particularly if you're using SSL. I couldn't say for certain if one is more secure than the other.
    – imclean
    Aug 16, 2018 at 5:07
  • Thinking about it, I think cookies are good when using non-destructive requests (GET). In such cases your JS library may take care of cookie authentication. When doing a POST or PATCH I believe the X-CSRF-Token header is required.
    – imclean
    Sep 5, 2018 at 6:40
  • So cookies work for POST and PATCH, but are they secure? Sep 11, 2018 at 1:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.