I’ve recently migrated a production server to a fresh new dedicated VPS using the official DO droplet. Used the documented backup and restore workflow for both content and members. Ghost is running latest 5.94.2. All functioning well and stable. However, my second admin user, whose credentials I have verified, is now unable to log in.
At the login screen, after entering the correct username and password, “Sign in” spins for an extended period of time before eventually returning a “There was a problem with the server” banner at top. If they instead use my login and password, it works fine. Same for me this end - my details work, theirs don’t. I have attempted to re-save and reset their password, this does not clear it up.
On the server errors logs, I see the following (redacted in the obvious places):
Again, this only happens for one user, but not for my personal admin user. The only difference I can think is that mine was created on new server setup, pre-migration, whereas his came across via the migration.
This is a weird one, any thoughts on what might be happening?
Ah, yes, seems there is an error in there. I won’t paste the whole thing, but it’s throwing NoPermissionError / “Authorization Failed” as soon as i hit submit on the login box, before the timing out request that I logged above. Note that this is not an incorrect password failure (or at least this is the password that worked on the old server), and I can make it throw the same error by attempting either to send a password reset, or to re-save password manually on the back end.
Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session
authentication.\"",
"stack":"NoPermissionError: Authorization failed
at authorizeAdminApi (/var/www/ghost/versions/5.94.2/core/server/services/auth/authorize.js:33:25)
at Layer.handle [as handle_request] (/var/www/ghost/versions/5.94.2/node_modules/express/lib/router/layer.js:95:5)
at next (/var/www/ghost/versions/5.94.2/node_modules/express/lib/router/route.js:149:13)
at authenticate (/var/www/ghost/versions/5.94.2/core/server/services/auth/session/middleware.js:28:13)”
...
Just in case, I’ve double checked that my transactional emails are also otherwise sending ok (via Mailgun smtp, successfully delivering in contexts outside of user management such as test email from post preview).
As a further note, I also appear to be having the same issue when trying to create an entirely new user, and I don’t believe this was the case after migration when I ran tests. So the migration might be a red herring. Attempted rollback to previous 5.94.0, same issue.
That’s what I’m getting at in that last post. Attempting to invite a new staff member causes the same issue. Click the button, nothing happens. It eventually responds with a 504 that I see in the javascript console, same error as the initial post with timeout in the nginx log, except pointed at http://127.0.0.1:2369/ghost/api/admin/invites/
It doesn’t seem to create an error in the actual ghost log though.
Something feels deeply wrong with the user management API in this install. I just tried a different site also on a DO droplet and same ghost general setup, it has the same issue. But current ghost version on my old server is still working fine. Only clear difference I can see is that the DO droplet uses Node 18, not 20, so I’m going to try upgrading that next.
Ok, so updating to node 20 changed the error. Attempting an invite returns a “check your email settings” on front end, and
,"stack":"EmailError: Failed to send email. Reason: Email has been temporarily rejected.
On the backend. Same now when I try to log in with the user that’s having issues, I get that error, followed by the original error.
I did test smtp was functioning after install, and it was, but it appears something’s up now. I’ve checked the config, and that the correct 587 port is open, and I have even sent a test email from the command line using the exact login credentials, which successfully delivers. No errors show for these failed ones in the mailgun logs. And it’s interesting that the issue is “temporary”. Hmph.
(And yes I did run a force update on Ghost to reinstall all modules after the node 20 update)
Leaving this here for posterity, I solved this - it was simply in the digital ocean default config the mail transport was set to “Direct”, rather than “SMTP” - i’d updated all the auth details but not that. Changing it to SMTP fixed it.
I think when I thought I was testing transactional emails, I must have actually just tested sending a preview of an article over email, which actually uses the bulk API.
The user login that was the initial issue was it trying to send a password reset email upon login.
With node 18, it returned timeouts rather than an email error, With node 20, we get the email error.