Extends the UI introduced in #12558 to have edit capabilities. (not in scope: "Add" for a new Authorized Integration will be the next update to this UI; `create-authorized-integration` CLI is still the only way to create a new record) This PR includes a few refactoring steps. The goal of these steps is to have `services/auth` be a single entrypoint for validating, inserting, or updating an authorized integration. Some logic is moved out of `services/authz` because it is not authorization related, and some is moved out of `services/auth/method` to allow it to be reused during validation without creating a cyclical module dependency. This PR also adds comprehensive validation to the more complex fields in the authorized integration, such as the issuer and claim rules. This validation applies to the `forgejo admin user create-authorized-integration` CLI as well. The visible UI is the same as #12558, but with a "Save" button, and the ability to display errors:  ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests for Go changes - I added test coverage for Go changes... - [x] in their respective `*_test.go` for unit tests. - [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I ran... - [x] `make pr-go` before pushing ### Tests for JavaScript changes - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [x] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [x] I did not document these changes and I do not expect someone else to do it. - Documentation is on my TODO list and will be completed before release. ### Release notes - [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change. - [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12601 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
68 lines
2.7 KiB
Go
68 lines
2.7 KiB
Go
// Copyright 2026 The Forgejo Authors. All rights reserved.
|
|
// SPDX-License-Identifier: GPL-3.0-or-later
|
|
|
|
package auth
|
|
|
|
import (
|
|
"testing"
|
|
|
|
"forgejo.org/modules/jwtx"
|
|
)
|
|
|
|
var internalIssuers = make(map[string]InternalIssuer)
|
|
|
|
// Authorized Integrations can verify the signature of JWTs that the application itself generated without requiring
|
|
// remote access, and in a manner that is flexible to changes in [setting.AppURL].
|
|
//
|
|
// For example, Forgejo Actions is often used to access Forgejo with a JWT, by setting `enable-openid-connect: true` in
|
|
// a workflow. Without any special support for this internal access situation, problems would occur:
|
|
//
|
|
// 1. Forgejo would need to make an HTTP request to itself to get the valid public key for the JWT, in order to validate
|
|
// its signature. This is a waste of resources, and introduces a self-DoS risk.
|
|
//
|
|
// 2. Forgejo would need to be available via TLS in order for Actions to make service calls to Forgejo with that JWT
|
|
// (due to the TLS requirement for public key fetching).
|
|
//
|
|
// 3. Authorized Integrations would need to be saved with the `issuer` URL of Forgejo. If Forgejo's own
|
|
// [setting.AppURL] changed, all the persisted records in the database would become incorrect.
|
|
//
|
|
// Internal Issuers work by registering a URL suffix like "api/actions". When a JWT is received with an issuer
|
|
// matching [setting.AppURL] and the registered URL suffix, then the [InternalIssuer] interface is used to access the
|
|
// JWT public key, and the value to be saved in the Authorized Integrations table as the issuer.
|
|
func RegisterInternalIssuer(urlSuffix string, internalIssuer InternalIssuer) {
|
|
internalIssuers[urlSuffix] = internalIssuer
|
|
}
|
|
|
|
// Variant of RegisterInternalIssuer which removes the registration impact in test cleanup.
|
|
func RegisterInternalIssuerForTesting(t *testing.T, urlSuffix string, internalIssuer InternalIssuer) {
|
|
orig, hadOrig := internalIssuers[urlSuffix]
|
|
internalIssuers[urlSuffix] = internalIssuer
|
|
t.Cleanup(func() {
|
|
if hadOrig {
|
|
internalIssuers[urlSuffix] = orig
|
|
} else {
|
|
delete(internalIssuers, urlSuffix)
|
|
}
|
|
})
|
|
}
|
|
|
|
// Retrieve an internal issuer, if one exists, for the provided URL suffix from a JWT token. For example,
|
|
// "api/actions".
|
|
func GetInternalIssuerByURLSuffix(issuerSuffix string) (InternalIssuer, bool) {
|
|
ii, ok := internalIssuers[issuerSuffix]
|
|
return ii, ok
|
|
}
|
|
|
|
// Read access to the registered internal issuers.
|
|
func GetInternalIssuers() map[string]InternalIssuer {
|
|
return internalIssuers
|
|
}
|
|
|
|
//mockery:generate: true
|
|
type InternalIssuer interface {
|
|
// Signing key used to validate a JWT from this internal issuer.
|
|
SigningKey() jwtx.SigningKey
|
|
// Value to store in [auth_model.AuthorizedIntegration]'s Issuer field to reflect the use of this internal issuer.
|
|
IssuerPlaceholder() string
|
|
}
|