Authentication not working

[mrobst]

    I've updated to latest version with the fix but it hasn't resolved my issue yet. After logon as soon as I go into a collection I get a 401 on /api/_preferences/collection-name . None of the collections will save. Will investigate further, any pointers on what to check appreciated

Originally posted by @mrobst in #1309 (comment)

[mrobst]

I cleared cookies and logged in. New cookie is set ok. No error. Then navigated to the first collection and I get a 401 error from /api/_preferences/categories-list with this log

[mrobst]

Working through the issue now. Its all working with postman using the jwt from the (failing) browser session as a bearer token. The request that is failing in the browser is using cookie: payload-token=xxx so I'm looking into this further to see if there is some config or problem with using cookies

[mrobst]

The issue is resolved by adding the csrf option to my buildConfig. I'm not sure yet a) how it worked at all after initial deployment, b) why it stopped working or c) why I need to add the (sub) domain for the admin page to the build options csrf.

Thinking about it though I'm using https://admin.mysite.com/admin for the URL and I think Payload expects to see https://mysite.com/admin so this is probably the explanation? (Context I'm hosting payload on DO and the front end site on a different provider so using the subdomain to handle the separate DNS).

Please let me know if I've resolved this the right way. Is there something in the documentation that I missed related to this? I don't mind contributing to update the docs if needed.

thanks
Marcus

[jmikrut]

Hey @mrobst — good catch RE: CSRF.

I think it's pretty tricky to properly diagnose a cookie being rejected due to CSRF reasons. Basically, if you have a serverURL defined, Payload will only allow a cross-origin cookie from that serverURL unless you explicitly define other domains that are safe.

This is obviously done for protection but it can be tough to expect.

I'm not sure yet a) how it worked at all after initial deployment, b) why it stopped working or c) why I need to add the (sub) domain for the admin page to the build options csrf.

Did you maybe add a serverURL at some point to your production instance? That would explain why it maybe started happening.

Regarding updating the docs, we do have lots of info about our CSRF prevention in the docs including a warning that says:

To protect against CSRF attacks, Payload only accepts cookie-based authentication from domains that you explicitly whitelist.

If you want to make it more clear or add context, I would be pumped. But personally I think the issue is more or less in the logging / reporting of why a cookie is rejected, when it is rejected. We could add a log to our JWT strategy that reports when an auth cookie is rejected due to CSRF.

What are your thoughts? PS - I'm gonna bump this to a discussion now that you've solved the issue so we can keep conversation going there. Maybe turn it into a feature request once we decide what to do to clarify this 👍

[mrobst]

Aaah (facepalm)! That helped me figure it out - my serverURL had http prefix and I'd moved to https so that was the problem. I've fixed the serverURL now and removed the manual addition of the csrf setting and its still working. Appreciate your replies to my thinking out loud!

Logging why a cookie was rejected would be useful but probably not a high priority for the moment.

[vimal-andiran]

Seeing 401 Unauthorized error on POST request . Works locally, but fails in dev environment despite being logged in.