2026-01-15 03:39:00 +01:00
|
|
|
// Copyright 2025 The Forgejo Authors. All rights reserved.
|
|
|
|
|
// SPDX-License-Identifier: GPL-3.0-or-later
|
|
|
|
|
|
|
|
|
|
package integration
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"crypto/rsa"
|
|
|
|
|
"encoding/base64"
|
feat: allow Forgejo Actions to be used an Authorized Integration in-memory with internal issuer (#12364)
Allow JWTs that are generated by Forgejo Actions to be validated within Forgejo in-memory. Without any special support for this internal access situation, these 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. This would be a blocker for writing end-to-end tests for Forgejo, but also would affect users who do not host Forgejo with TLS.
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.
## 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.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
### Release notes
- [ ] 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.
- [x] 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/12364
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
2026-05-01 17:42:34 +02:00
|
|
|
"fmt"
|
2026-01-15 03:39:00 +01:00
|
|
|
"math/big"
|
|
|
|
|
"net/http"
|
|
|
|
|
"testing"
|
|
|
|
|
|
|
|
|
|
actions_model "forgejo.org/models/actions"
|
feat: allow Forgejo Actions to be used an Authorized Integration in-memory with internal issuer (#12364)
Allow JWTs that are generated by Forgejo Actions to be validated within Forgejo in-memory. Without any special support for this internal access situation, these 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. This would be a blocker for writing end-to-end tests for Forgejo, but also would affect users who do not host Forgejo with TLS.
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.
## 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.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
### Release notes
- [ ] 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.
- [x] 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/12364
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
2026-05-01 17:42:34 +02:00
|
|
|
"forgejo.org/models/auth"
|
2026-01-15 03:39:00 +01:00
|
|
|
"forgejo.org/models/db"
|
|
|
|
|
"forgejo.org/modules/setting"
|
feat: allow Forgejo Actions to be used an Authorized Integration in-memory with internal issuer (#12364)
Allow JWTs that are generated by Forgejo Actions to be validated within Forgejo in-memory. Without any special support for this internal access situation, these 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. This would be a blocker for writing end-to-end tests for Forgejo, but also would affect users who do not host Forgejo with TLS.
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.
## 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.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
### Release notes
- [ ] 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.
- [x] 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/12364
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
2026-05-01 17:42:34 +02:00
|
|
|
api "forgejo.org/modules/structs"
|
2026-01-15 03:39:00 +01:00
|
|
|
actions_service "forgejo.org/services/actions"
|
|
|
|
|
"forgejo.org/tests"
|
|
|
|
|
|
|
|
|
|
"github.com/golang-jwt/jwt/v5"
|
|
|
|
|
"github.com/stretchr/testify/assert"
|
|
|
|
|
"github.com/stretchr/testify/require"
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
type getTokenResponse struct {
|
|
|
|
|
Value string `json:"value"`
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func prepareTestEnvActionsIDToken(t *testing.T) func() {
|
|
|
|
|
t.Helper()
|
|
|
|
|
f := tests.PrepareTestEnv(t, 1)
|
|
|
|
|
return f
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestActionsIDToken(t *testing.T) {
|
|
|
|
|
defer prepareTestEnvActionsIDToken(t)()
|
|
|
|
|
task, err := actions_model.GetTaskByID(db.DefaultContext, 48)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
err = task.LoadAttributes(db.DefaultContext)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gitCtx, err := actions_service.GenerateGiteaContext(task.Job.Run, task.Job)
|
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
|
|
token, err := actions_service.CreateAuthorizationToken(task, gitCtx, true)
|
|
|
|
|
require.NoError(t, err)
|
fix: prevent actions workflows from generating OIDC tokens if not authorized in workflow (#12030)
When using Forgejo's `enable-openid-connect: true`, a URL is generated into the actions under `$ACTIONS_ID_TOKEN_REQUEST_URL` that can be used to generate a JWT for accessing third-party resources authenticated as the action executing in this server on this repo. However, the endpoint of that url (`.../idtoken`) had unintentionally missed a `return` on an internal server error, and was missing a check that the action actually had `enable-openid-connect: true` on it. As a result, it was possible to generate a JWT for accessing third-party resources from an action that wasn't expected to be generating JWTs.
In terms of real-world vulnerability, the most likely risk is that the JWT could be generated from a forked pull request. By not using the `$ACTIONS_ID_TOKEN_REQUEST_URL` and instead going directly to the `.../idtoken` endpoint, and parsing a generated JWT response that will be mixed with an error response, it's possible to retrieve a JWT in a forked pull request. It would require a slight misconfiguration on a third-party system to allow that JWT access, but it's a plausible risk.
As this is a feature in Forgejo 15 that hasn't been released, it will be fixed in-public.
## 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
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
### Release notes
- [ ] 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.
- [x] 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.
- Feature is not yet released.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12030
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
2026-04-08 15:42:39 +02:00
|
|
|
tokenWithoutOIDCAccess, err := actions_service.CreateAuthorizationToken(task, gitCtx, false)
|
|
|
|
|
require.NoError(t, err)
|
2026-01-15 03:39:00 +01:00
|
|
|
|
|
|
|
|
// get JWKs information
|
|
|
|
|
req := NewRequest(t, "GET", "/api/actions/.well-known/keys")
|
|
|
|
|
resp := MakeRequest(t, req, http.StatusOK)
|
|
|
|
|
var jwks jwksResponse
|
|
|
|
|
DecodeJSON(t, resp, &jwks)
|
|
|
|
|
require.Len(t, jwks["keys"], 1)
|
|
|
|
|
key := jwks["keys"][0]
|
|
|
|
|
|
|
|
|
|
var exponent []byte
|
|
|
|
|
if exponent, err = base64.RawURLEncoding.DecodeString(key["e"]); err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var modulus []byte
|
|
|
|
|
if modulus, err = base64.RawURLEncoding.DecodeString(key["n"]); err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pubKey := rsa.PublicKey{
|
|
|
|
|
E: int(big.NewInt(0).SetBytes(exponent).Uint64()),
|
|
|
|
|
N: big.NewInt(0).SetBytes(modulus),
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
t.Run("success path", func(t *testing.T) {
|
|
|
|
|
doAssertions := func(aud string, claims map[string]any) {
|
|
|
|
|
assert.Equal(t, "user1", claims["actor"])
|
|
|
|
|
assert.Equal(t, aud, claims["aud"])
|
|
|
|
|
assert.Equal(t, setting.AppURL+"api/actions", claims["iss"])
|
|
|
|
|
assert.Equal(t, "refs/heads/master", claims["ref"])
|
|
|
|
|
assert.Equal(t, "false", claims["ref_protected"])
|
|
|
|
|
assert.Equal(t, "branch", claims["ref_type"])
|
|
|
|
|
assert.Equal(t, "user5/repo4", claims["repository"])
|
|
|
|
|
assert.Equal(t, "user5", claims["repository_owner"])
|
|
|
|
|
assert.Equal(t, "1", claims["run_attempt"])
|
|
|
|
|
assert.Equal(t, "792", claims["run_id"])
|
|
|
|
|
assert.Equal(t, "188", claims["run_number"])
|
|
|
|
|
assert.Equal(t, "c2d72f548424103f01ee1dc02889c1e2bff816b0", claims["sha"])
|
|
|
|
|
assert.Equal(t, "repo:user5/repo4:ref:refs/heads/master", claims["sub"])
|
|
|
|
|
assert.Equal(t, "artifact.yaml", claims["workflow"])
|
|
|
|
|
assert.Equal(t, "user5/repo4/.forgejo/workflows/artifact.yaml@refs/heads/master", claims["workflow_ref"])
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Default aud
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/792/idtoken?placeholder=true").AddTokenAuth(token)
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusOK)
|
|
|
|
|
var getResponse getTokenResponse
|
|
|
|
|
DecodeJSON(t, resp, &getResponse)
|
|
|
|
|
|
|
|
|
|
claims := jwt.MapClaims{}
|
|
|
|
|
_, err = jwt.ParseWithClaims(getResponse.Value, claims, func(t *jwt.Token) (any, error) {
|
|
|
|
|
return &pubKey, nil
|
|
|
|
|
})
|
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
|
|
doAssertions(setting.AppURL+"user5", claims)
|
|
|
|
|
|
|
|
|
|
// Custom aud
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/792/idtoken?placeholder=true&audience=testingAud").AddTokenAuth(token)
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusOK)
|
|
|
|
|
DecodeJSON(t, resp, &getResponse)
|
|
|
|
|
|
|
|
|
|
claims = jwt.MapClaims{}
|
|
|
|
|
_, err = jwt.ParseWithClaims(getResponse.Value, claims, func(t *jwt.Token) (any, error) {
|
|
|
|
|
return &pubKey, nil
|
|
|
|
|
})
|
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
|
|
doAssertions("testingAud", claims)
|
|
|
|
|
})
|
|
|
|
|
|
fix: prevent actions workflows from generating OIDC tokens if not authorized in workflow (#12030)
When using Forgejo's `enable-openid-connect: true`, a URL is generated into the actions under `$ACTIONS_ID_TOKEN_REQUEST_URL` that can be used to generate a JWT for accessing third-party resources authenticated as the action executing in this server on this repo. However, the endpoint of that url (`.../idtoken`) had unintentionally missed a `return` on an internal server error, and was missing a check that the action actually had `enable-openid-connect: true` on it. As a result, it was possible to generate a JWT for accessing third-party resources from an action that wasn't expected to be generating JWTs.
In terms of real-world vulnerability, the most likely risk is that the JWT could be generated from a forked pull request. By not using the `$ACTIONS_ID_TOKEN_REQUEST_URL` and instead going directly to the `.../idtoken` endpoint, and parsing a generated JWT response that will be mixed with an error response, it's possible to retrieve a JWT in a forked pull request. It would require a slight misconfiguration on a third-party system to allow that JWT access, but it's a plausible risk.
As this is a feature in Forgejo 15 that hasn't been released, it will be fixed in-public.
## 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
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
### Release notes
- [ ] 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.
- [x] 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.
- Feature is not yet released.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12030
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
2026-04-08 15:42:39 +02:00
|
|
|
t.Run("with token that doesn't support OIDC", func(t *testing.T) {
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/792/idtoken?placeholder=true").AddTokenAuth(tokenWithoutOIDCAccess)
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusInternalServerError)
|
|
|
|
|
assert.Contains(t, resp.Body.String(), "Error runner api parsing custom claims")
|
|
|
|
|
assert.NotContains(t, resp.Body.String(), "value") // must not leak an actual `getTokenResponse`
|
|
|
|
|
})
|
|
|
|
|
|
2026-01-15 03:39:00 +01:00
|
|
|
t.Run("with no auth header", func(t *testing.T) {
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/792/idtoken?placeholder=true&audience=testingAud")
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusUnauthorized)
|
|
|
|
|
assert.Contains(t, resp.Body.String(), "Bad authorization header")
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
t.Run("with bad token format", func(t *testing.T) {
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/792/idtoken?placeholder=true&audience=testingAud").AddTokenAuth("1234567")
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusInternalServerError)
|
|
|
|
|
assert.Contains(t, resp.Body.String(), "Error runner api parsing authorization token")
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
t.Run("with invalid task", func(t *testing.T) {
|
|
|
|
|
task, err := actions_model.GetTaskByID(db.DefaultContext, 48)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
err = task.LoadAttributes(db.DefaultContext)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
// Change ID to be invalid
|
|
|
|
|
task.ID = 123456
|
|
|
|
|
|
|
|
|
|
gitCtx, err := actions_service.GenerateGiteaContext(task.Job.Run, task.Job)
|
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
|
|
token, err := actions_service.CreateAuthorizationToken(task, gitCtx, true)
|
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/abcde/idtoken?placeholder=true&audience=testingAud").AddTokenAuth(token)
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusInternalServerError)
|
|
|
|
|
assert.Contains(t, resp.Body.String(), "Error runner api getting task by ID")
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
t.Run("with task that is not running", func(t *testing.T) {
|
|
|
|
|
task, err := actions_model.GetTaskByID(db.DefaultContext, 49)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
err = task.LoadAttributes(db.DefaultContext)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
gitCtx, err := actions_service.GenerateGiteaContext(task.Job.Run, task.Job)
|
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
|
|
token, err := actions_service.CreateAuthorizationToken(task, gitCtx, true)
|
|
|
|
|
require.NoError(t, err)
|
|
|
|
|
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/abcde/idtoken?placeholder=true&audience=testingAud").AddTokenAuth(token)
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusInternalServerError)
|
|
|
|
|
assert.Contains(t, resp.Body.String(), "Error runner api getting task: task is not running")
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
t.Run("with mismatched run ID", func(t *testing.T) {
|
|
|
|
|
req = NewRequest(t, "GET", "/api/actions/_apis/pipelines/workflows/123/idtoken?placeholder=true&audience=testingAud").AddTokenAuth(token)
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusBadRequest)
|
|
|
|
|
assert.Contains(t, resp.Body.String(), "run-id does not match")
|
|
|
|
|
})
|
feat: allow Forgejo Actions to be used an Authorized Integration in-memory with internal issuer (#12364)
Allow JWTs that are generated by Forgejo Actions to be validated within Forgejo in-memory. Without any special support for this internal access situation, these 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. This would be a blocker for writing end-to-end tests for Forgejo, but also would affect users who do not host Forgejo with TLS.
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.
## 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.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### 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.
### Release notes
- [ ] 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.
- [x] 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/12364
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
2026-05-01 17:42:34 +02:00
|
|
|
|
|
|
|
|
t.Run("authorized integration internal issuer", func(t *testing.T) {
|
|
|
|
|
// Create an Authorized Integration which is set-up to be validated with the in-memory Actions' JWT signing key:
|
|
|
|
|
ai := &auth.AuthorizedIntegration{
|
|
|
|
|
UserID: 2,
|
|
|
|
|
Scope: auth.AccessTokenScopeAll,
|
|
|
|
|
Issuer: "urn:forgejo:authorized-integrations:actions",
|
|
|
|
|
ClaimRules: &auth.ClaimRules{
|
|
|
|
|
Rules: []auth.ClaimRule{
|
|
|
|
|
{
|
|
|
|
|
Claim: "sub",
|
|
|
|
|
Comparison: auth.ClaimEqual,
|
|
|
|
|
Value: "repo:user5/repo4:ref:refs/heads/master",
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
ResourceAllRepos: true,
|
|
|
|
|
}
|
|
|
|
|
require.NoError(t, auth.InsertAuthorizedIntegration(t.Context(), ai))
|
|
|
|
|
|
|
|
|
|
// Create a JWT from the Actions system:
|
|
|
|
|
var getResponse getTokenResponse
|
|
|
|
|
req = NewRequest(t, "GET", fmt.Sprintf("/api/actions/_apis/pipelines/workflows/792/idtoken?placeholder=true&audience=%s", ai.Audience)).AddTokenAuth(token)
|
|
|
|
|
resp = MakeRequest(t, req, http.StatusOK)
|
|
|
|
|
DecodeJSON(t, resp, &getResponse)
|
|
|
|
|
|
|
|
|
|
// Should be able to make a Forgejo API call with the JWT, authenticated by the Authorized Integration:
|
|
|
|
|
req := NewRequest(t, "GET", "/api/v1/user").AddTokenAuth(getResponse.Value)
|
|
|
|
|
resp := MakeRequest(t, req, http.StatusOK)
|
|
|
|
|
var user api.User
|
|
|
|
|
DecodeJSON(t, resp, &user)
|
|
|
|
|
assert.Equal(t, "user2", user.LoginName)
|
|
|
|
|
})
|
2026-01-15 03:39:00 +01:00
|
|
|
}
|