Getting req.user as null after logging in via GraphQL from client.

[itzaks]

Bug Report

I'm currently logging in on a collection using graphql. Right now the collection setup looks like this.

  auth: true, // Auth is enabled,

  access: {
    read: () => true,
    create: () => true
  },

I'm using an Authorization header on the graphql requests that looks like

{"Authorization": "JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpb(...)"}

Using the token that I got back from logging in via graphql.

When testing it in the graphql playground I'm getting null response on token and user. It seems like req.user is null when I debug the me-operation. Any ideas what I'm doing wrong?

{
  "data": {
    "mePublicUser": {
      "token": null,
      "user": null
    }
  }
}

[itzaks]

After some digging I thought it had to do with the response cookie not being set from the server, since I hadn't configured credentials: 'include' on my cors-graphql request, and then I configured the auth to look like this:

  auth: {
    cookies: {
      secure: true,
      sameSite: 'none'
    }
  },

I now see the cookie payload-token in my response cookies, but still I'm getting null in the me-queries. What am I missing here?

[jmikrut]

HEy @itzaks —

Couple clarifying things for ya quick:

I believe you should only need to specify credentials: 'include' on fetches if you are relying on Payload's HTTP-only cookie to authenticate.

But if you are specifying the Authorization header directly, that will override the HTTP cookie. So it seems to me like you might be trying to do both here.

Anyway, that's just background info.

I just tried to recreate your issue on the Payload demo (https://demo.payloadcms.com/api/graphql-playground) but I can't. I even used Postman to run a meUser directly from the demo's GraphQL endpoint.

I expect something else is amiss here, and it's just a small issue with your setup. If you can create a minimally reproducible repo, I am happy to help diagnose further! Let's keep the convo going in a discussion.

[itzaks]

Thanks for clarifying @jmikrut! Makes sense.

When digging down into a bare minimum reproduction, I found that the cause of this issue is another Collection that has a different, custom, authentication strategy.

These following lines are responsible for setting up the auth strategy for my separate ClientUser collection.

  auth: {
    disableLocalStrategy: true,
    strategies: [{
      strategy: (ctx) =>
        new MagicLoginStrategy(ctx, 'client-user', process.env.MAGIC_LINK_SECRET),
      name: 'magicLogin'
    }]
  },

If I change it to simply auth: true, my me-queries resolve as usual. Any ideas on what I'm doing wrong here?

[jmikrut]

Honestly it’s probably that auth strategy. Not knowing the specifics, I bet that it hijacks requests and redirects you somewhere if you are not logged in - therefore not allowing our built in auth strategies to run.

One thing I would say is that most auth strategies are not built to authenticate API routes AND UI routes. Probably the cause of why your strategy isn’t working.

[itzaks]

Sounds fair. I wrote the strategy myself so it's probably something to look through then. But I'm curious as to why it affects a collection it shouldn't even be used on?

[itzaks]

I marked it as answered now :-) however I think there is something going on with using multiple auth strategies that could be worth looking in to.

[jacobsfletch]

Related: #1902