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

itzakslast year

1 3

  auth: true, // Auth is enabled,

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

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

• Selected Answer
  

  jmikrut

  last year

  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.

  4 replies
• 

  itzakslast year

  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

  last year

  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.

• 

  itzakslast year

  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?

• 

  itzakslast year

  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.

• 

  itzakslast year

  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?

• 

  jacobsfletch

  last year

  Related: #1902