No helpful errors when attempting to login without email setup #23050

jrockwar · 2025-04-26T23:12:23Z

Issue Summary

After upgrading from ghost:5.117.0-alpine to ghost:5.118.0-alpine, admin login is broken: no cookies are set in the browser, and Ghost logs show 403 errors with "Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session authentication."
Rolling back to ghost:5.117.0-alpine or earlier resolves the issue.

Steps to Reproduce

Deploy Ghost using Docker with the ghost:5.118.0-alpine or ghost:5.118.1-alpine image.
Use a standard nginx reverse proxy (as per this tutorial).
Try to log in to /ghost/#/signin from a new browser or incognito window.
Observe that no cookies are set and login fails with a 403.
Revert Docker with ghost:5.117.0-alpine
Try to log in to /ghost/#/signin from a new browser or incognito window. Login works successfully.
Redeploy with the ghost:5.118.x-alpine image and try to login again. Login fails as described in (4)

If using the same browser that did the initial set-up, then the cookie is already set and login can be completed successfully.

Ghost Version

5.118.0 / 5.118.1

Node.js Version

v18.20.8

How did you install Ghost?

docker-alpine in a Hetzner VPS (Arm64 CAX11); via docker compose as per https://community.hetzner.com/tutorials/ghost-cms-on-arm64-debian

Database type

MySQL 8

Browser & OS version

Tested on MacOS Sequoia: Zen (Firefox) / Chromium / Safari; Android 15: Iceraven (Firefox), Chrome

Relevant log / error output

[2025-04-26 21:06:34] ERROR "GET /ghost/api/admin/users/me/?include=roles" 403 6ms

Authorization failed

"Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session authentication."

Error ID:
    55d2b170-22e2-11f0-90d2-31b40eaea8c0

----------------------------------------

NoPermissionError: Authorization failed
    at authorizeAdminApi (/var/lib/ghost/versions/5.118.1/core/server/services/auth/authorize.js:33:25)
    at Layer.handle [as handle_request] (/var/lib/ghost/versions/5.118.1/node_modules/express/lib/router/layer.js:95:5)
    at next (/var/lib/ghost/versions/5.118.1/node_modules/express/lib/router/route.js:149:13)
    at authenticate (/var/lib/ghost/versions/5.118.1/core/server/services/auth/session/middleware.js:55:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Code of Conduct

I agree to be friendly and polite to people in this repository

The text was updated successfully, but these errors were encountered:

ErisDS · 2025-04-27T07:18:17Z

Hi @jrockwar, that's all the expected behaviour with our new Device Verification security feature.

https://ghost.org/changelog/2fa/
https://github.com/TryGhost/Ghost/releases/tag/v5.118.0

The 403 error returned from the signin request itself will tell you that a code is required or what's wrong if there was an issue sending the code

The 403 from the request to GET /ghost/api/admin/users/me/?include=roles" is not the request to signin, this is the request used by the admin panel to determine if you're already logged in before showing you the signin screen, you'll see that request and 403 prior to 5.118 as well.

What's curious is you're not getting an error message related to email sending failure or some other issue that clarifies what's going wrong. Are you able to share the log from the actual signin request, which is to the ghost/api/admin/sessions/ endpoint?

github-actions · 2025-04-27T07:18:42Z

Note from our bot: The needs:info label has been added to this issue. Updating your original issue with more details is great, but won't notify us, so please make sure you leave a comment so that we can see when you've updated us.

jrockwar · 2025-04-27T08:11:53Z

Thanks for replying @ErisDS ! This makes sense as email wasn't (isn't) configured yet in my freshly setup blog, so ghost couldn't have sent emails for verification.

However what I don't understand then is:

Why, as you say, I didn't get any other message with ERROR severity on the logs (from the browser point of view, the failure on the login page was completely silent and the page just hung).
Why the browser/device pair used for the initial setup of the blog can login successfully as staff without email being set up.

I think I saw some INFO messages about email, but nothing that sounded too ominous. I'll try to get you more logs / info so you can see whether this is expected behavior or a genuine issue.

In any case, different problem but there are dozens of tutorials out there for setting up ghost that assume that email isn't required but very much an optional step; it'd be great to update documentation to say it's now a hard requirement. This might make it inviable for some applications like internal documentation for teams on self-hosted environments where it's not feasible/practical to have a mailserver.

jrockwar · 2025-04-27T08:57:24Z

This is a less-truncated version of the ghost logs:

[2025-04-27 08:51:30] INFO "GET /ghost/" 200 30ms
[2025-04-27 08:51:30] ERROR "GET /ghost/api/admin/users/me/?include=roles" 403 6ms

Authorization failed

"Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session authentication."

Error ID:
    d00f3050-2344-11f0-a9d7-5d84571a68b5

----------------------------------------

NoPermissionError: Authorization failed
    at authorizeAdminApi (/var/lib/ghost/versions/5.118.0/core/server/services/auth/authorize.js:33:25)
    at Layer.handle [as handle_request] (/var/lib/ghost/versions/5.118.0/node_modules/express/lib/router/layer.js:95:5)
    at next (/var/lib/ghost/versions/5.118.0/node_modules/express/lib/router/route.js:149:13)
    at authenticate (/var/lib/ghost/versions/5.118.0/core/server/services/auth/session/middleware.js:55:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

[2025-04-27 08:51:30] INFO "GET /ghost/api/admin/site/" 200 6ms
[2025-04-27 08:51:30] INFO "GET /ghost/api/admin/authentication/setup/" 200 10ms
[2025-04-27 08:51:33] WARN Missing mail.from config, falling back to a generated email address. Please update your config file and set a valid from address
[2025-04-27 08:51:33] WARN Missing mail.from config, falling back to a generated email address. Please update your config file and set a valid from address
[2025-04-27 08:52:55] INFO "POST /ghost/api/admin/session" 200 100006ms
[2025-04-27 08:53:13] INFO "POST /ghost/api/admin/session" 200 100006ms

So there is a warning in there about the email. Plus if I leave it long enough, there is a... timeout? after 100 seconds.

However, interestingly, when I go to Settings > Staff, the setting for 2FA is disabled (note I never disabled it manually - this is how it came by default when I setup the blog on 5.118.1):

On the browser side, all I get after 100 seconds is:

Nothing is telling me in an obvious way that:

The email sending is failing
That email configuration is mandatory
That 2FA for Staff accounts is mandatory (or even enabled)
That 2FA for Staff accounts is failing

jrockwar · 2025-04-27T09:00:58Z

I have also tried enabling Require email 2FA codes to be used on all staff logins and the output I get is identical - no new info on the logs or error message about any of the above. I think at the very least this should be more verbose, shouldn't it?

cathysarisky · 2025-04-27T23:05:30Z

Hey @jrockwar

ErisDS left some helpful links to documentation over on the forum: https://forum.ghost.org/t/cant-login-to-admin-dashboard-on-more-than-one-device/57135/3 - worth a read, if you haven't seen it yet.

As I understand it, that toggle affects whether all staff logins (new or old device) require a code, vs whether just new devices do. (So it doesn't really turn the behavior off, just reduces it. But the link above includes how to turn the behavior entirely off, if you need to. [It'd probably be better to configure outbound email instead, but...]

ErisDS · 2025-05-01T12:32:19Z

A little update here - all the behaviour of Ghost reported here is expected EXCEPT for the lack of clear error messaging.

I definitely want to make all of this more transparent so it's easier to debug and fix, as well as making it clearer that email is required.

There's quite a few bits to do around docs and error handling.

One thing I don't have on this issue that would be SUPER helpful is a really, really clear reproduction case.

E.g. either step-by-step bullets outlining exactly what you did OR a screencast of you going through the motions would be amazingly helpful. It would significantly speed up the time it'll take me to find and resolve the issues, as well as ensure that I get the exact right cases.

(To be clear, when I run ghost locally for development I get super clear error messages, so it's not like this is the most obvious case)

ErisDS · 2025-05-01T12:32:50Z

Alternatively of course if anyone else can already reproduce it, fixes are welcome!

jrockwar · 2025-05-01T12:43:50Z

Hi @ErisDS, Unfortunately I can't reproduce it anymore because now I've set up email properly in my blog, but up until then it was super easy to reproduce. I've written steps to reproduce (on the description). Set up: - Create a ghost blog from the docker image I've linked in the description, with v5.118+ - Login to domain.com/ghost (this will work, and initially prompt the blog set up). After set up: - After the blog has been set up try logging in again: This will still work - Open an incognito browser or a browser on any other computer, go to domain.com/ghost: you won't be able to log-in, and the log in will hang. To "fix" the issue: - Revert the docker compose image to 5.117, relaunch ghost via docker compose down/up. - Try to log in on an incognito browser or other computer (that hasn't logged in before): the issue is gone. - If you then go back to 5.118, login on a new browser hangs again. alternatively, - Keep docker on 5.118 but enable email - Then things work as intended, as the login page sends an authentication email. The details of my compose .yaml are in the link provided in the description - I followed that tutorial verbatim.

…

On May 1 2025, at 1:32 PM, Hannah Wolfe ***@***.***> wrote: ErisDS left a comment (TryGhost/Ghost#23050) (#23050 (comment)) A little update here - all the behaviour of Ghost reported here is expected EXCEPT for the lack of clear error messaging. I definitely want to make all of this more transparent so it's easier to debug and fix, as well as making it clearer that email is required. There's quite a few bits to do around docs and error handling. One thing I don't have on this issue that would be SUPER helpful is a really, really clear reproduction case. E.g. either step-by-step bullets outlining exactly what you did OR a screencast of you going through the motions would be amazingly helpful. It would significantly speed up the time it'll take me to find and resolve the issues, as well as ensure that I get the exact right cases. (To be clear, when I run ghost locally for development I get super clear error messages, so it's not like this is the most obvious case) — Reply to this email directly, view it on GitHub (#23050 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AHS5OVLJW2KPJ7FYVCW6NTT24IH6TAVCNFSM6AAAAAB354LMROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBUG42TAOJXGA). You are receiving this because you were mentioned.

pong106 · 2025-05-03T08:55:09Z

temporary fix or bypass to turn off Auth code

https://ghost.org/docs/config/#security

security__staffDeviceVerification for docker

JERXCHRS · 2025-05-10T13:36:11Z

Thanks for replying @ErisDS ! This makes sense as email wasn't (isn't) configured yet in my freshly setup blog, so ghost couldn't have sent emails for verification.

However what I don't understand then is:

Why, as you say, I didn't get any other message with ERROR severity on the logs (from the browser point of view, the failure on the login page was completely silent and the page just hung).

Why the browser/device pair used for the initial setup of the blog can login successfully as staff without email being set up.

I think I saw some INFO messages about email, but nothing that sounded too ominous. I'll try to get you more logs / info so you can see whether this is expected behavior or a genuine issue.

In any case, different problem but there are dozens of tutorials out there for setting up ghost that assume that email isn't required but very much an optional step; it'd be great to update documentation to say it's now a hard requirement. This might make it inviable for some applications like internal documentation for teams on self-hosted environments where it's not feasible/practical to have a mailserver.

I second this. There have been so many published guides on how to pull this off because it’s not feasible for many. After this update hit I can’t login to admin panel without figuring out how to again setup mailgun which honestly, many don’t want to use. Would have been nice to have a heads up and trial this option not making it required by default giving self-hosting community time to deal with setup before being locked out.

ironicbadger · 2025-05-13T14:15:16Z

Holy moly this took an hour of my life. Thank you to @pong106 for the workaround my goodness. No error messages, nothing in the logs even in debug mode. How does stuff like this get past QA?

I added

environment:
	- security__staffDeviceVerification=false

to my compose file and can now login again.

procrastinando · 2025-05-14T12:46:49Z

Holy moly this took an hour of my life. Thank you to @pong106 for the workaround my goodness. No error messages, nothing in the logs even in debug mode. How does stuff like this get past QA?

I added
environment:
	- security__staffDeviceVerification=false
to my compose file and can now login again.

Thank goodness! That’s exactly what I needed. I was on the verge of rebuilding my blog from the beginning today.

ironicbadger · 2025-05-14T13:19:46Z

I am not even really clear on how to configure things with my user so I can remove this line either.

aa6my · 2025-05-21T09:21:36Z

temporary fix or bypass to turn off Auth code

https://ghost.org/docs/config/#security

security__staffDeviceVerification for docker

for kubernetes
kubectl edit deployment ghost

env:
- name: url
  value: https://yourdomain.com
- name: security__staffDeviceVerification
  value: "false"

kubectl rollout restart deployment ghost

damusix · 2025-05-25T15:50:11Z

Holy moly this took an hour of my life. Thank you to @pong106 for the workaround my goodness. No error messages, nothing in the logs even in debug mode. How does stuff like this get past QA?

I added
environment:
	- security__staffDeviceVerification=false
to my compose file and can now login again.

Yeah this was frustrating. Thanks for the fix. More frustrating that I encountered it intermittently after deploy 3 separate sites. There are zero error messages that indicate what's going on, which is bad DX @ErisDS

dogukansahil · 2025-05-26T15:18:03Z

Holy moly this took an hour of my life. Thank you to @pong106 for the workaround my goodness. No error messages, nothing in the logs even in debug mode. How does stuff like this get past QA?
I added
environment:
	- security__staffDeviceVerification=false
to my compose file and can now login again.
Yeah this was frustrating. Thanks for the fix. More frustrating that I encountered it intermittently after deploy 3 separate sites. There are zero error messages that indicate what's going on, which is bad DX @ErisDS

This definitely worked for casaos. I am grateful

ChairBorn · 2025-05-28T20:21:07Z

temporary fix or bypass to turn off Auth code

https://ghost.org/docs/config/#security

security__staffDeviceVerification for docker

I spent 2 days of my life looking for an answer to this... thank you, that worked

github-actions bot added the needs:triage [triage] this needs to be triaged by the Ghost team label Apr 26, 2025

jrockwar changed the title ~~Regression: Admin login/session cookies broken in ghost:5.118.1-alpine (works in 5.117.0-alpine and earlier)~~ Regression: Admin login/session cookies broken in ghost:5.118.0-alpine (works in 5.117.0-alpine and earlier) Apr 26, 2025

ErisDS added the needs:info [triage] Blocked on missing information label Apr 27, 2025

github-actions bot removed the needs:triage [triage] this needs to be triaged by the Ghost team label Apr 27, 2025

jrockwar changed the title ~~Regression: Admin login/session cookies broken in ghost:5.118.0-alpine (works in 5.117.0-alpine and earlier)~~ Admin login/session cookies broken in ghost:5.118.0-alpine (works in 5.117.0-alpine and earlier) on ghost without email setup Apr 27, 2025

ErisDS changed the title ~~Admin login/session cookies broken in ghost:5.118.0-alpine (works in 5.117.0-alpine and earlier) on ghost without email setup~~ No helpful errors when attempting to login without email setup May 1, 2025

ErisDS added bug [triage] something behaving unexpectedly and removed needs:info [triage] Blocked on missing information labels May 1, 2025

Uh oh!

No helpful errors when attempting to login without email setup #23050

No helpful errors when attempting to login without email setup #23050

Comments

jrockwar commented Apr 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issue Summary

Steps to Reproduce

Ghost Version

Node.js Version

How did you install Ghost?

Database type

Browser & OS version

Relevant log / error output

Code of Conduct

ErisDS commented Apr 27, 2025

Uh oh!

github-actions bot commented Apr 27, 2025

Uh oh!

jrockwar commented Apr 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jrockwar commented Apr 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jrockwar commented Apr 27, 2025

Uh oh!

cathysarisky commented Apr 27, 2025

Uh oh!

ErisDS commented May 1, 2025

Uh oh!

ErisDS commented May 1, 2025

Uh oh!

jrockwar commented May 1, 2025 via email

Uh oh!

pong106 commented May 3, 2025

Uh oh!

JERXCHRS commented May 10, 2025

Uh oh!

ironicbadger commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

procrastinando commented May 14, 2025

Uh oh!

ironicbadger commented May 14, 2025

Uh oh!

aa6my commented May 21, 2025

Uh oh!

damusix commented May 25, 2025

Uh oh!

dogukansahil commented May 26, 2025

Uh oh!

ChairBorn commented May 28, 2025

Uh oh!

jrockwar commented Apr 26, 2025 •

edited

Loading

jrockwar commented Apr 27, 2025 •

edited

Loading

jrockwar commented Apr 27, 2025 •

edited

Loading

ironicbadger commented May 13, 2025 •

edited

Loading