{"exp":1701269391,"message":"Auth Passed","token":"xxx","user":{"id":"643b1704cebf9086bf5eb679","name":"Admin","enableAPIKey":true,"email":"admin@xxx.io","createdAt":"2023-04-15T21:28:37.399Z","updatedAt":"2023-11-29T12:48:51.991Z","apiKey":"xxx"}}

/api/users/me

{"user":null}

lezon05232 years ago
did you add credentials: 'include' in the request?

I mean when u request /api/users/me
botabit2 years ago
No, this is on the webui.

The payload-token cookie is set with a jwt
notchr2 years ago
@869921544682491904
To clarify, you're saying that Payload is making a request that is not getting the session?

Or you added a custom request and it's not getting the session

?
botabit2 years ago
That's correct, this is a payload application hosted on a cloud service. From a UI perspective, I log in and nothing happens.

The network calls are as above where it appears to be correctly generating a JWT on the login request but then the second request returns null
notchr2 years ago
I've seen this issue before, and it's hard to say exactly the origin, but from what I remember it was the Payload configuration

Either the Loading indicator stalls or the admin page is blank with errors

What are the status codes of the errors?

Maybe we can narrow down the cause
botabit2 years ago
The status is 200, it doesn't get past the login screen

Is there any form of enhanced logs I can run to get some more infomation for you?
notchr2 years ago
Interesting, could you paste your payload configuration here, redact any personal info

botabit2 years ago

import { buildConfig } from "payload/config";
import { mongooseAdapter } from "@payloadcms/db-mongodb";
import { slateEditor } from "@payloadcms/richtext-slate";
import { webpackBundler } from "@payloadcms/bundler-webpack";
import path from "path";

import Sites from "./collections/Sites";
import ContentGroup from "./collections/ContentGroup";
import Posts from "./collections/Posts";
import Users from "./collections/Users";
import Media from "./collections/Media";
import Prompts from "./collections/Prompts";
import Scripts from "./collections/Scripts";

export default buildConfig({
  serverURL: process.env.SERVER_URL,
  rateLimit: {
    skip: () => true,
  },
  admin: {
    user: Users.slug,

    bundler: webpackBundler(),
  },
  collections: [Sites, ContentGroup, Posts, Users, Media, Scripts, Prompts],
  typescript: {
    outputFile: path.resolve(__dirname, "payload-types.ts"),
  },
  graphQL: {
    schemaOutputFile: path.resolve(__dirname, "generated-schema.graphql"),
  },
  express: {
    json: {
      // @ts-ignore
      limit: "400MB",
    },
  },

  db: mongooseAdapter({
    url: process.env.MONGODB_URI,
  }),
  editor: slateEditor({}),
});

notchr2 years ago
Are you able to confirm the value process.env.SERVER_URL via a console.log
botabit2 years ago
https://xx.azurewebsites.net

where xx is the deployed name
notchr2 years ago
Ah I see so it's on a subdomain

I'm not 100% sure this is the issue, but I know when you host on a subdomain, nginx can get a bit funky

https://nouance.io/articles/how-to-host-payloadcms-on-a-subdomain-and-subpath-with-nginx

@858693520012476436
has a solid article on this

Let me know if that looks like a potential solution, if not I can help investigate more
botabit2 years ago
What would be the scenario here? The request domain is being modified by azures load balancer (not using nginx)?

Shouldn't that have prevented the login request from working as well?
notchr2 years ago
Well, it may have been able to hit the endpoint, returning a 200, but no user because maybe the cookie being saved doesn't match what is expected

Thats one guess

You could take the jwt from the request header and drop it in
https://jwt.io

and check out the value of the jwt to see if anything looks suspicious

That would be my first step I think
botabit2 years ago
This is the jwt from the /login request, the payload-cookie is an exact match to the one /login responds with.
notchr2 years ago
Hmmm
botabit2 years ago
invalid signature
notchr2 years ago
It's going to be invalid without the secret key, you can ignore that

Hmmm
botabit2 years ago
Would it be useful to set some breakpoints around the /me request?
notchr2 years ago
Well if it were custom code I'd say yes, but the login page has been battle tested pretty heavily

I'm still leaning towards this being an issue with the configuration + the subdomain

But that's kind of hard to tell without the ability to easily modify your nginx / server host configuration

I'm hoping Paul jumps in here, they may have a better idea on how to resolve this..I'm still brainstorming here
paulpopus2 years ago
The first thing I see that's missing in your config is the CORS bit

So whatever your deployed url is, you need to add
cors: ['https://url.azure.net']
like this

worth setting
csrf
as well

here is my config:
```
cors: Boolean(process.env.CORS)
  ? CORS.split(',')
  : ['http://localhost:3001'],
csrf: Boolean(process.env.CSRF)
  ? CSRF.split(',')
  : ['http://localhost:3001'],
```
then in my env vars I add a value for
CORS
and
CSRF
with comma separated strings
notchr2 years ago
Ah good call
@858693520012476436
botabit2 years ago
After redeploying with the cors and csrf tags unfortunately not much has changed.
paulpopus2 years ago
unfortunately for this sort of thing its easier to debug with the actual site at hand, you able to share that?
notchr2 years ago
^
paulpopus2 years ago
It's been solved! I think it was the cors/csrf issue!

On the second hand his requests in firefox were cached, but it's resolved now
notchr2 years ago
YASSS

@858693520012476436
check out this one
https://discord.com/channels/967097582721572934/1179384093805383720

Open

Continue the discussion in Discord

Star on GitHub

Star

Chat on Discord

Discord

online

Can't find what you're looking for?

Get dedicated engineering support directly from the Payload team.