jojo/routers/common/auth.go

47 lines
1.2 KiB
Go
Raw Normal View History

// Copyright 2022 The Gitea Authors. All rights reserved.
// SPDX-License-Identifier: MIT
package common
import (
"forgejo.org/modules/web/middleware"
auth_service "forgejo.org/services/auth"
"forgejo.org/services/context"
)
[v15.0/forgejo] refactor: clarify four different outputs that authentication methods provide (#12468) **Backport:** https://codeberg.org/forgejo/forgejo/pulls/12231 #12202 began a refactor of Forgejo's authentication implementations by providing structured data on an authentication success. However, error cases were maintained as-is in that refactor, leaving a complex situation: what does returning an error from an authentication method mean?; does it mean that the authentication failed, or that a server error occurred? Can another authentication still be tried? This PR changes authentication methods so that they can return one of four things: - `AuthenticationSuccess` with an authentication result. - `AuthenticationNotAttempted` which indicates that no credentials relevant for this authentication method were presented. If every method returned `AuthenticationNotAttempted`, then you would have an unauthenticated access. - `AuthenticationAttemptedIncorrectCredential` which indicates that credentials were present and failed validation -- a situation indicating a `401 Unauthorized`. - `AuthenticationError` which indicates that an internal server error occurred and failed authentication -- indicating a `500 Internal Server Error`. This paves the way for one more refactor coming next: `basic.go` and `oauth2.go` perform 3-4 different authentications each (access tokens, oauth JWTs, actions tokens, actions JWTs, and username/password). With the capability to return these more precise responses, these authentication methods can be split up into separate logic that isn't intertwined together. Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12468 Reviewed-by: Gusted <gusted@noreply.codeberg.org>
2026-05-08 07:31:33 +02:00
func AuthShared(ctx *context.Base, sessionStore auth_service.SessionStore, authMethod auth_service.Method) auth_service.MethodOutput {
output := authMethod.Verify(ctx.Req, ctx.Resp, sessionStore)
var ar auth_service.AuthenticationResult
switch v := output.(type) {
case *auth_service.AuthenticationSuccess:
ar = v.Result
case *auth_service.AuthenticationNotAttempted:
ar = &auth_service.UnauthenticatedResult{}
}
[v15.0/forgejo] refactor: clarify four different outputs that authentication methods provide (#12468) **Backport:** https://codeberg.org/forgejo/forgejo/pulls/12231 #12202 began a refactor of Forgejo's authentication implementations by providing structured data on an authentication success. However, error cases were maintained as-is in that refactor, leaving a complex situation: what does returning an error from an authentication method mean?; does it mean that the authentication failed, or that a server error occurred? Can another authentication still be tried? This PR changes authentication methods so that they can return one of four things: - `AuthenticationSuccess` with an authentication result. - `AuthenticationNotAttempted` which indicates that no credentials relevant for this authentication method were presented. If every method returned `AuthenticationNotAttempted`, then you would have an unauthenticated access. - `AuthenticationAttemptedIncorrectCredential` which indicates that credentials were present and failed validation -- a situation indicating a `401 Unauthorized`. - `AuthenticationError` which indicates that an internal server error occurred and failed authentication -- indicating a `500 Internal Server Error`. This paves the way for one more refactor coming next: `basic.go` and `oauth2.go` perform 3-4 different authentications each (access tokens, oauth JWTs, actions tokens, actions JWTs, and username/password). With the capability to return these more precise responses, these authentication methods can be split up into separate logic that isn't intertwined together. Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12468 Reviewed-by: Gusted <gusted@noreply.codeberg.org>
2026-05-08 07:31:33 +02:00
if ar != nil {
doer := ar.User()
if doer != nil {
if ctx.Locale.Language() != doer.Language {
ctx.Locale = middleware.Locale(ctx.Resp, ctx.Req)
}
ctx.Data["IsSigned"] = true
ctx.Data[middleware.ContextDataKeySignedUser] = doer
ctx.Data["SignedUserID"] = doer.ID
ctx.Data["IsAdmin"] = doer.IsAdmin
} else {
ctx.Data["IsSigned"] = false
ctx.Data["SignedUserID"] = int64(0)
}
}
[v15.0/forgejo] refactor: clarify four different outputs that authentication methods provide (#12468) **Backport:** https://codeberg.org/forgejo/forgejo/pulls/12231 #12202 began a refactor of Forgejo's authentication implementations by providing structured data on an authentication success. However, error cases were maintained as-is in that refactor, leaving a complex situation: what does returning an error from an authentication method mean?; does it mean that the authentication failed, or that a server error occurred? Can another authentication still be tried? This PR changes authentication methods so that they can return one of four things: - `AuthenticationSuccess` with an authentication result. - `AuthenticationNotAttempted` which indicates that no credentials relevant for this authentication method were presented. If every method returned `AuthenticationNotAttempted`, then you would have an unauthenticated access. - `AuthenticationAttemptedIncorrectCredential` which indicates that credentials were present and failed validation -- a situation indicating a `401 Unauthorized`. - `AuthenticationError` which indicates that an internal server error occurred and failed authentication -- indicating a `500 Internal Server Error`. This paves the way for one more refactor coming next: `basic.go` and `oauth2.go` perform 3-4 different authentications each (access tokens, oauth JWTs, actions tokens, actions JWTs, and username/password). With the capability to return these more precise responses, these authentication methods can be split up into separate logic that isn't intertwined together. Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12468 Reviewed-by: Gusted <gusted@noreply.codeberg.org>
2026-05-08 07:31:33 +02:00
return output
}
// VerifyOptions contains required or check options
type VerifyOptions struct {
SignInRequired bool
SignOutRequired bool
AdminRequired bool
DisableCSRF bool
}