5 Commits

Author	SHA1	Message	Date
bircni	c0f89a373d	fix(auth): do not auto-reactivate disabled users on OAuth2 callback (#38009) (#38183) ... Backport #38009 The OAuth2 sign-in callback unconditionally set IsActive=true on the local user row whenever the IdP authenticated them, silently undoing an administrator's "Disable Account" action and granting the user a fresh session in the same response. Treat the local IsActive flag as an authoritative admin override: inactive users get a session and are routed through the existing activate / prohibit-login pages by verifyAuthWithOptions, matching the local-credentials sign-in path. Adds an integration regression test that disables a linked local user and asserts the row stays IsActive=false after a full OIDC callback. Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>	2026-06-28 02:24:00 -05:00
Lunny Xiao	26ad4fd03f	fix(auth): ignore stale OIDC external login links to organizations (#37875) (#38141) ... Backport #37875 This fixes an OIDC sign-in edge case where a stale `external_login_user` record can still point to an organization or a deleted user. In that situation, Gitea may keep resolving the external login to the wrong account during sign-in. For affected instances, this matches the behavior reported in #36439 and #37812, where a user signing in with OIDC/Entra ID could appear as an organization, or hit a 404 after that organization was removed. - validate the user resolved from `external_login_user` during OAuth2/OIDC login - ignore stale links when the linked user no longer exists - ignore stale links when the linked user is not an individual user - remove the stale external login row so the sign-in flow can relink the external account to the correct user - Fixes #37812 - Related to #36439 Co-authored-by: silverwind <me@silverwind.io> Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com> Co-authored-by: bircni <bircni@icloud.com>	2026-06-28 02:20:21 -05:00
Jonathan Miller	9a5720e8ad	chore: rename Go module from git. to code.mokoconsulting.tech (#336) ... Full namespace migration: update the Go module path and all import statements from git.mokoconsulting.tech to code.mokoconsulting.tech. Also updates all URL references in templates, workflows, configs, tests, and documentation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-31 10:28:25 -05:00
Jonathan Miller	c572fcfe04	chore(core): rename Go module from code.gitea.io/gitea to MokoGitea namespace ... Rename the Go module path from code.gitea.io/gitea to git.mokoconsulting.tech/MokoConsulting/MokoGitea across the entire codebase. Scope: - go.mod module declaration - 2,235 Go source files (import paths) - Dockerfile WORKDIR and COPY paths - Swagger API templates - golangci.yml linter config External dependencies (code.gitea.io/gitea-vet, code.gitea.io/sdk/gitea, gitea.com/gitea/act, etc.) are intentionally NOT renamed — they are separate upstream modules. Closes #132 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-05-25 00:22:38 -05:00
Zettat123	b1bfca39f1	Add ExternalIDClaim option for OAuth2 OIDC auth source (#37229) ... This PR adds an External ID Claim Name configuration field to the OIDC auth source. When set, Gitea uses the specified JWT claim as the user's `ExternalID` instead of the default `sub` claim. This PR fixes the bug when migrating from Azure AD V2 to OIDC. When an admin migrates the same auth source to OIDC, goth's `openidConnect` provider defaults to using the `sub` claim as `UserID`. However, Azure AD's `sub` is a pairwise identifier: > `sub`: The subject is a pairwise identifier and is unique to an application ID. If a single user signs into two different apps using two different client IDs, those apps receive two different values for the subject claim. https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference#payload-claims As a result, every existing user appears as a new account after migration. To fix this issue, Gitea should use `oid` claim for `UserID`. > `oid`: This ID uniquely identifies the user across applications - two different applications signing in the same user receives the same value in the oid claim. Note: The `oid` claim is not included in Azure AD tokens by default. The `profile` scope must be added to the Scopes field of the auth source.	2026-04-16 17:30:46 +00:00