This is a implementation of #4277.
The core idea is that any activity (where activity is defined as anything that ends up in the `action` table) will be wrapped in an `ap.Note`, and sent to followers. Similarly, the inbox of local users now accepts such Notes. Additionally, there's now a "Feeds" tab on the user profile page, which displays the received notes.
# Preview
# How to Try?
The PR can be tried using a single Forgejo instance, but two distinct ones probably shows how it works better. For the sake of simplicity, lets try with a single instance. This is how to get started:
1. Enable federation
2. Subscribe one user to another (or to themselves):
```
curl -s -H "authorization: Bearer ${TOKEN}" -XPOST \
http://localhost:3000/api/v1/user/activitypub/follow \
--json '{"target": "http://localhost:3000/api/v1/activitypub/user-id/1"}'
```
This makes the first user follow themselves.
3. Create a repo, open an issue, or basically do anything that results in an activity recorded.
4. Visit `http://localhost:3000/{username}?tab=feed` to see the feed in action.
If you want to try with multiple instances, then it's very similar: you just change the `actor_id` to the IRI of the user you want to follow the first instance's user with, and then you can look at the feed tab of this user on the second instance, after you performed some activity on the first.
## Trying with Mastodon / GoToSocial
To try with Mastodon or GoToSocial, you will likely need to bring your Forgejo instance public, and behind https. Once your Forgejo instance is up, you can search for `@yourusername@forgejo.your.domain.example.com`, and simply follow your Forgejo account. Creating any activity will then happily federate to Mastodon & GoToSocial.
You can also copy & paste the Forge user's web profile URL (eg, `https://forgejo.your.domain.example.com/yourusername`) into your fedi client of choice, and it will discover the profile that way too.
# Testing
* test: https://codeberg.org/meissa/federation/src/branch/federated-user-activity-following/doc/user-activity-following/manual-test.md
* Proof of gts->forgejo: https://social.meissa-gmbh.de/@meissa/114499541149466596
* Proof of forgejo->gts: https://social.meissa-gmbh.de/@meissa/114505225265720094
## Architecture decisions
There are a number of ways user activity federation could be implemented. One way - which I explored first - is to wrap each activity, and send those, and let the client render it. The advantage of this would be that we'd be able to have references to other objects (comments, repos, etc). The disadvantage is that doing this requires making all of these things addressable, and that's a lot of work. Another disadvantage is that this requires every client to know how to display it.
Another way, chosen here, is to send a rendered HTML `ap.Note` instead, with an `AttributedTo` (`ap.Person`) property, which describes the activity that happened in a HTML note. This is much simpler to implement, and has the huge advantage that it is also easier to display. In fact, once we have http signatures, we should be able to federate user activity to Mastodon, too! (Though this also requires figuring out how Mastodon wants to follow a user...)
Since user activity federation is mostly cosmetic, as in, it's there for the user to see, rather than for programs to take actions based upon this activity, I believe that sending an `ap.Note` is preferable over a more machine-oriented approach.
## Limitations & TODO
### FederatedUser
We should be caching the Avatar in a similar way. For that, though, we also need to store the last activity of a federated user, so we can expire old avatars from the cache. The avatar refresh part will be covered by #4778.
### Notes
While sending out notes, the `AttributedTo` property is set to an `ap.Person`, based on the originating local user. This is currently unused. The idea is that once following is implemented properly (see above), we'll be able to link this to a FederatedUser (and thus to ExternalUser & User), which will allow us to display avatars and such, too.
### Display
The template used for displaying the received activities is currently incredibly simplistic. That's probably ok, it doesn't need to be fantastic.
### TODO
- [x] Fix the crashes on certain ops:
- [x] Issue/PR close & reopen
- [x] Figure out a better way to implement follows
- [x] Store the `AttributedTo` part of the note, too, the ID of it.
- [x] Make sure only those activities are sent out that need to be.
Currently, pretty much any activity is sent out, even private ones. We should be a bit smarter about that.
- [x] Make the ids used in the AP messages deterministic
The IDs used in the AP messages are currently UUIDs, and we do not store them, so all the IRIs are "invalid": the objects they refer to don't exist outside of the AP message itself. We should be able to reconstruct the Note objects and Create activities from their IDs.
- [x] Make it possible to follow Forgejo account from Mastodon and GtS
- [x] Mastodon without `AUTHORIZED_FETCH` works
- [x] GoToSocial can follow
- [x] Mastodon with `AUTHORIZED_FETCH` can follow
- ~~Create a cron job to refresh federated user avatars~~
- [x] Implement unfollowing
- [x] Add a `<link rel="alternate" type="application/activity+json" href="...">` to profile pages
This lets Mastodon & most other Fedi frontends discover the AP profile just by pasting a Forgejo user's web profile page into a search box, without having to know the corresponding AP actor URL
- [x] Make it easier to make a local user follow a remote AP actor
- ~~Rebase on top of #4778 by @realaravinth, once that is ready~~
- [x] Create an API endpoint to list the AP feed
- [x] Create a DB migration for the new stuff
- [x] Make swagger stuff happy
- [x] Clean up the commit history
- [x] ~~Tests~~ Opting for manual testing for now.
Co-authored-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-authored-by: jerger <jerger@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4767
Reviewed-by: jerger <jerger@noreply.codeberg.org>
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
The dialog element shrink wrap up to the max-width boundary. The
`long-modal` is set to strictly fit the `800px` width in the test.
However with Playwright minor font rendering differences makes the
dialog modal width resulting in `797px`.
Test fails at: [expect(width).toBe(800);](6132d0e406/tests/e2e/modal.test.e2e.ts (L103))
The fix is to increase the content of the `#long-model` element in
`templates/demo/model.tmpl` to 300 characters length instead of the
current `100` characters length ensures that the dialog modal will always
hit the `800px` max-width.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12469
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Some notes:
- I didn't write integration tests because it's a pure bugfix that addresses implementation details of the model layer.
- I can see interpretations of "it involves interactions with a live Forgejo server" that would cover this PR, but they don't make sense to me in context.
- I didn't add anything to the documentation because it's a pure bugfix - the system should always have worked this way
- there's no value in confusing people trying to figure out how the system works now with how it didn't work in the past
- However, there IS value in informing people who may have gotten bitten by this in the past, so I think a release note makes sense
- These fixes are closely related, and the changes small, so I decided to make just one PR.
- From a user perspective, this is just one issue, and I think in terms of release notes, it makes more sense to have just this one.
- Technically, fixing only one of the underlying issues would be enough. Since this is a case of invalid states being representable, it makes sense to both try to prevent it happening in the first place, and deal with it gracefully if it does happen.
- At the very least, fixing #12245 is required unless we want to live with data generated in the past being broken
Fixes#12243Fixes#12245
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12302
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
For Agit-flow pull requests, `head.label` was explicitly set to an empty
string. The head branch name (which contains the Agit topic,
e.g. `user2/my-topic`) was already populated from `pr.HeadBranch` but then
discarded.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12352
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Cyborus <cyborus@disroot.org>
While the changes were conveyed in the pull request in its entirety, the commit
history of a pull request having more than one commit was bugged and the log
would have shown just the presence of the most recent commit event, having the
entire changes contained in a pull request.
This is a problem that was mostly noticed in the closed pull request, so it is
not as bad as it looks. Even then, if we are migrating closed pull requests, we
should do it the right way. We do not want to retain these pull requests for
archival purposes if they are not accurate.
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
Fixes https://forge.fedoraproject.org/forge/forge/issues/556
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12433
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
This changes the ReqHTTPSignature middleware to cover the entire activitypub
route group to not miss any new routes again in the future. Further, this adds
a tests iterating through all activitypub routes to test that the signature
verification is actually done.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12339
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: elle <0xllx0@noreply.codeberg.org>
See #12353 for more details
## 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.
- [ ] 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.
- [ ] 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.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12441
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
- Regression of forgejo/forgejo!11776 (and forgejo/forgejo!11881)
- Scope of the transaction is moved to a per-package cleanup rule basis.
This is also a enhancement for scaling (already deployed on Codeberg for a while).
- Package cleanup is now run with `RetryTx`, because rebuilding
repository files runs `RetryTx` and it could indicate to retry the whole
transaction.
- Previously it would error and say running `RetryTx` in a
transaction was not possible, this is now possible. Nested `RetryTx` is
always allowed, matching of which errors to retry is still the responsible
of the inner `RetryTx`.
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12446
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
This pr PR is fixing a type introduced in #10397. In case of an error during the creation of the centralised hooks `git.InitFull` would have returned early, missing some of the configuration steps
## 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.
- [ ] 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
(can be removed for Go changes)
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] 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.
- [ ] 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.
- [ ] 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.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12427
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
In the case you hit some API error (Github ratelimit was often a problem) or the instance restarted in the middle of your migration, you would be left with data on the disk and/or database. Upon retrying the migration the migration code would (rightfully) fail because it's trying to migrate stuff that already exists.
This was hit so often on Codeberg it was better to force people to delete and start whole migration process again: 28ee60c91f
Delete the repository data before retrying to solve this.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12370
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Follow-up to https://code.forgejo.org/forgejo/runner/pulls/1509 -- improves the UX in Forgejo when a reusable workflow is skipped, marking the workflow as skipped rather than succeeded.
## 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
### 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
- [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/12412
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
User interfaces for authorized integrations will benefit from having a name field, to allow a list of authorized integrations to have an identifiable user-entered label.
I've also added a "description" column which is a `LONGTEXT` field. My thought for this field is that if I were creating authorized integrations, I'd like to be able to write down where they're used, what they're used for, and how the remote system is configured. For example, if it was an authorized integration to allow AWS -> Forgejo integration, the AWS side can be complicated -- IAM roles which are assumed, resources like EC2 instances or Lambdas that can access the roles -- and this would provide a natural place to make some notes to help me remember how the remote is configured. I expect to represent this as a `<textarea>` in the Authorized Integration, optional, possibly markdown-formatted to allow links & bullet-points.
Manually tested migration with PG backend, and manually tested creation of authorized integrations with the CLI updates.
## 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...
- [ ] 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
### 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/12413
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Both #12355 and #12364 passed CIs individually, but when combined a new test added in #12364 was broken by the change in #12355. Fixes the authorized integration test to use the new immutable subject format.
## 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...
- [ ] 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/12401
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Protect OIDC tokens generated by Forgejo Actions from threats arising when users or repositories are renamed or deleted, freeing their names up for reuse by another user. In this threat environment, relying on the name of users and repositories in validating JWT claims is unsafe because they can change.
Adds three new claims to Actions' OIDC tokens:
- `actor_id` -- the immutable identifier of the actor who triggered an Action run
- `repository_id` -- the immutable identifier of the repository on which the Action is running
- `repository_owner_id` -- the immutable identifier of the owner of the repository on which the Action is running
Repositories will change their subject (`sub`) OIDC claims to include these immutable identifiers. Existing repositories will not change, in order to maintain compatibility with existing JWT usage. The new format will be applied to new repositories, or can be applied by disabling and enabling the Actions unit. The new format embeds the identifiers:
- **Existing repos:** `repo:my-org/my-repo:ref:refs/heads/main`
- **New repos:** `repo:my-org-123456/my-repo-456789:ref:refs/heads/main`
Fixes#12244.
## 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
### Documentation
- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- New fields will be added to documentation soon.
- [ ] I did not document these changes and I do not expect someone else to do it.
### 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/12355
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
## Fix: `GET /api/v1/repos/{owner}/{repo}/git/tags/{sha}` returns empty verification for signed tags
### Problem
When an annotated tag is signed (GPG or SSH) but the underlying commit is **not** signed, the API endpoint `GET /repos/{owner}/{repo}/git/tags/{sha}` returns an empty `verification.signature` field.
This is because `ToAnnotatedTag` was calling `ToVerification(ctx, c)` with the **commit** object, which checks the commit's signature — not the tag's own signature. Since the commit is unsigned, the API returns `signature: ""` and `verified: false`.
This causes issues for tools that rely on the tag signature from the API to validate that a tag push event is from a trusted source.
### Fix
`ToAnnotatedTag` now checks if the tag has its own signature (`t.Signature != nil`). If so, it uses `ParseTagWithSignature` to verify the tag's signature and populates the `verification` field from the tag. Otherwise, it falls back to the commit signature (existing behavior for unsigned/lightweight tags).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12351
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Allows user to assign organization projects to their new issues, using the project sidebar selector, even when repository's projects are disabled.
Moreover, the project sidebar selector is now hidden if no projects (repository-wide + organization-wide) are available.
Fixesforgejo/forgejo#5666
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7999
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Allows us to make use of Go features introduced in v1.26.
I require a feature from v1.26 for a PR I want to make later.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12369
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Having tooltip only for `lfs_pointers.accessible` is fine in English, but not in other languages. For other languages the text is truncated.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12139
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
github.com/robfig/cron is used for parsing cron schedules of scheduled Forgejo Actions workflows. It has not seen an update in roughly six years and looks abandoned. There are multiple code paths that trigger panics instead of errors. It is replaced by github.com/gdgvda/cron, which is one of the few maintained forks. github.com/gdgvda/cron was picked because its behaviour is fully backwards-compatible and the developers are responsive.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12365
Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
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>
