[Bug] SSO no longer working #148

Closed
opened 2026-10-05 01:44:47 +02:00 by adam · 5 comments
Owner

Hi,

After upgrading today, the SSO functionality no longer works, e.g. when cliking sign in with auth.mydomain.dev it just briefly shows redirecting in the button, but nothing more.

Nothing is logged related to this as far as I can tell, only on startup this:

Aug 21 11:56:20 gitea-mirror bun[95372]: ]
Aug 21 11:56:20 gitea-mirror bun[95372]: 2026-08-21T09:56:20.186Z WARN [Better Auth]: Please ensure '/.well-known/oauth-authorization-server/api/auth' exists. Upon completion, clear with silenceWarnings.oauthAuthServerConfig.
Aug 21 11:56:20 gitea-mirror bun[95372]:  Initializing shutdown manager and signal handlers...

My Config:

Image
Hi, After upgrading today, the SSO functionality no longer works, e.g. when cliking sign in with auth.mydomain.dev it just briefly shows redirecting in the button, but nothing more. Nothing is logged related to this as far as I can tell, only on startup this: ```bash Aug 21 11:56:20 gitea-mirror bun[95372]: ] Aug 21 11:56:20 gitea-mirror bun[95372]: 2026-08-21T09:56:20.186Z WARN [Better Auth]: Please ensure '/.well-known/oauth-authorization-server/api/auth' exists. Upon completion, clear with silenceWarnings.oauthAuthServerConfig. Aug 21 11:56:20 gitea-mirror bun[95372]:  Initializing shutdown manager and signal handlers... ``` My Config: <img width="825" height="383" alt="Image" src="https://github.com/user-attachments/assets/19148ec5-fd34-4847-9618-31bde86536fc" /> <!-- github-sync-id:5213037526 -->
adam closed this issue 2026-10-05 01:44:47 +02:00
Author
Owner

Also, have you got any idea what this means?

Aug 21 11:56:20 gitea-mirror bun[95372]: [Scheduler] Auto-start conditions met for user XXX (scheduleEnabled=true)
Aug 21 11:56:20 gitea-mirror bun[95372]: [Repository Cleanup] Processing 1 configurations
Aug 21 11:56:20 gitea-mirror bun[95372]: [Repository Cleanup] Starting repository cleanup for user XXX 
Aug 21 11:56:20 gitea-mirror bun[95372]: [Repository Cleanup] Warning: CLEANUP_DELETE_FROM_GITEA is false but CLEANUP_DELETE_IF_NOT_IN_GITHUB is true. Proceeding with cleanup.
Aug 21 11:56:20 gitea-mirror bun[95372]: [Scheduler] Auto-start detected from environment variables, triggering initial import and mirror...

I don't want repos that are deleted from github to be removed from gitea-mirror, but not deleted from my forgejo instance

Also, have you got any idea what this means? ```bash Aug 21 11:56:20 gitea-mirror bun[95372]: [Scheduler] Auto-start conditions met for user XXX (scheduleEnabled=true) Aug 21 11:56:20 gitea-mirror bun[95372]: [Repository Cleanup] Processing 1 configurations Aug 21 11:56:20 gitea-mirror bun[95372]: [Repository Cleanup] Starting repository cleanup for user XXX Aug 21 11:56:20 gitea-mirror bun[95372]: [Repository Cleanup] Warning: CLEANUP_DELETE_FROM_GITEA is false but CLEANUP_DELETE_IF_NOT_IN_GITHUB is true. Proceeding with cleanup. Aug 21 11:56:20 gitea-mirror bun[95372]: [Scheduler] Auto-start detected from environment variables, triggering initial import and mirror... ``` I don't want repos that are deleted from github to be removed from gitea-mirror, but not deleted from my forgejo instance <!-- github-comment-id:5368579104 -->
Author
Owner

@CrazyWolf13 from which version did you update? any idea?

@CrazyWolf13 from which version did you update? any idea? <!-- github-comment-id:5369356106 -->
Author
Owner

@arunavo4 most likely from 3.26.2 two versions up to latest.

@arunavo4 most likely from 3.26.2 two versions up to latest. <!-- github-comment-id:5369506623 -->
Author
Owner

@CrazyWolf13 Found it, and it's not actually a 3.26 -> 3.27 thing. The auth library we use shipped SSRF hardening that landed in gitea-mirror v3.21.0 (mid July). Since then, every SSO sign-in resolves your IdP's hostname and rejects it with a 400 if it points at a private address. If auth.yourdomain.dev resolves to a LAN IP from inside the container (split DNS), sign-in dies right there. The reason it felt like a fresh regression: sessions last 30 days, so you only hit the sign-in path again when your session expired. And the login UI swallowed the error completely, which is why you just saw "Redirecting..." flip back with nothing in the logs. That part was our bug.

Fixed in v3.27.2:

  • Providers you've registered are now trusted automatically, so this just works again with no config changes. Update and sign in.
  • SSO errors now show up as an actual error message instead of silently doing nothing.

If you want to confirm the diagnosis before updating: dev tools > Network, click the SSO button, check the response of POST /api/auth/sign-in/sso. It'll say something like "not publicly routable... add its origin to trustedOrigins". Adding BETTER_AUTH_TRUSTED_ORIGINS=https://auth.yourdomain.dev to your env also fixes it on any version, if you'd rather not update yet.

On the cleanup warning: turns out CLEANUP_DELETE_FROM_GITEA did nothing at all, which is also fixed in v3.27.2. It now works the way you'd expect: with it false (the default), orphaned repos are only archived/removed in gitea-mirror's own list and your Forgejo is never touched. Set CLEANUP_ORPHANED_REPO_ACTION=delete if you want them gone from the list entirely, archive (default) if you want them kept but marked. Heads up for anyone who relied on the old behavior: it used to archive repos on the Gitea side even with the flag off, so if you actually want that, set CLEANUP_DELETE_FROM_GITEA=true.

@CrazyWolf13 Found it, and it's not actually a 3.26 -> 3.27 thing. The auth library we use shipped SSRF hardening that landed in gitea-mirror v3.21.0 (mid July). Since then, every SSO sign-in resolves your IdP's hostname and rejects it with a 400 if it points at a private address. If auth.yourdomain.dev resolves to a LAN IP from inside the container (split DNS), sign-in dies right there. The reason it felt like a fresh regression: sessions last 30 days, so you only hit the sign-in path again when your session expired. And the login UI swallowed the error completely, which is why you just saw "Redirecting..." flip back with nothing in the logs. That part was our bug. Fixed in v3.27.2: - Providers you've registered are now trusted automatically, so this just works again with no config changes. Update and sign in. - SSO errors now show up as an actual error message instead of silently doing nothing. If you want to confirm the diagnosis before updating: dev tools > Network, click the SSO button, check the response of POST /api/auth/sign-in/sso. It'll say something like "not publicly routable... add its origin to trustedOrigins". Adding `BETTER_AUTH_TRUSTED_ORIGINS=https://auth.yourdomain.dev` to your env also fixes it on any version, if you'd rather not update yet. On the cleanup warning: turns out CLEANUP_DELETE_FROM_GITEA did nothing at all, which is also fixed in v3.27.2. It now works the way you'd expect: with it false (the default), orphaned repos are only archived/removed in gitea-mirror's own list and your Forgejo is never touched. Set CLEANUP_ORPHANED_REPO_ACTION=delete if you want them gone from the list entirely, archive (default) if you want them kept but marked. Heads up for anyone who relied on the old behavior: it used to archive repos on the Gitea side even with the flag off, so if you actually want that, set CLEANUP_DELETE_FROM_GITEA=true. <!-- github-comment-id:5369669088 -->
Author
Owner

thanks, appreciate the quick fix :)

It's working again.

thanks, appreciate the quick fix :) It's working again. <!-- github-comment-id:5369986053 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/gitea-mirror#148