mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2026-07-25 19:07:59 +00:00
18 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
forgejo-backport-action
|
1ce675fc1c |
[v16.0/forgejo] fix: REQUIRE_SIGNIN_VIEW caches setting before setting initialization (#13307)
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/13304 Regression in #12776 -- `[service].REQUIRE_SIGNIN_VIEW` and `[service.explore].REQUIRE_SIGNIN_VIEW` values were being cached into a constructed middleware during module initialization, before the `settings` object had been initialized by reading settings from the config. As a result, neither setting applied to the middleware. Apparently zero automated tests cover this capability. Fixed by changing the bool into a closure for realtime access to the setting. Added automated tests. Verified that the tests failed when broken. ### 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. - Prerelease regression. Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13307 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
forgejo-backport-action
|
a5a2cae7ee |
[v16.0/forgejo] chore(refactor): add getter/setter to APIContext data members (#13213)
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/13143 The details of the refactor are in [a separate branch](https://codeberg.org/limiting-factor/forgejo/commits/branch/wip-api-context-accessors-save) which details how it was done. This pull request contains a squash of those commits rebased on top of the current Forgejo branch, which involved conflict resolution. Given the magnitude of the change, there is a high chance that a large number of future pull requests merged in Forgejo will create conflicts. They will be dealt with in the same way as chore: refactor orgAssignment to two separate middlewares (#13155). ## Review The only risk I can think of is a getter/setter implementation being incorrectly implemented. This is probably where a detailed review is most needed, in the `services/context/api.go` file. To not increase the size of the pull request, the `GetX()` accessors were preserved although they are redundant with `X()`. They will be removed in a followup pull request. ## Backporting strategy. Cherry-picking the commit to v15 has a significant amount of conflicts in 8 files out of 111. ``` unmerged routers/api/v1/activitypub/repository.go unmerged routers/api/v1/admin/user.go unmerged routers/api/v1/api.go unmerged routers/api/v1/org/team.go unmerged routers/api/v1/repo/action.go unmerged routers/api/v1/repo/pull.go unmerged routers/api/v1/user/follower.go unmerged services/context/api.go ``` Instead of resolving them, I think it is easier and safer to repeat the [refactor steps](https://codeberg.org/limiting-factor/forgejo/commits/branch/wip-api-context-accessors-save) in v15. I also think it is worth the effort since it will avoid trivial backport conflicts on over 100 files. ## Context This is a followup pull request discussed originally at https://codeberg.org/forgejo/forgejo/pulls/12512 Co-authored-by: limiting-factor <limiting-factor@posteo.com> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13213 Reviewed-by: limiting-factor <limiting-factor@noreply.codeberg.org> Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
limiting-factor
|
65e35d2ba0 |
chore(refactor): run routers/api/v1/permissions/tests from tests/integration (#13157)
Changing the tests introduced in [this pull request](https://codeberg.org/forgejo/forgejo/pulls/12512) to run from the integration directory instead of running from a package, makes it possible to backport to v15. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/13157 Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org> |
||
|
limiting-factor
|
b296496356 |
chore: refactor REST API permission check | ||
|
Mathieu Fenniak
|
de5f38c4ea |
feat: enable auth to raw resources, release downloads, & attachments via authorized integrations (#12776)
A handful of routes, described in this PR as "mixed routes", are currently accessible by both web-based sessions and authenticated API users. The goal of this PR is to allow access to these routes for Authorized Integrations as well, bringing them to full API compatibility (to my knowledge) with other authentication methods. These routes are impacted:
- `/{username}/{repo}/raw/*`
- `/{username}/{repo}/archive/*`
- `/{username}/{repo}/releases/download/{vTag}/{fileName}`
- `/{username}/{repo}/attachments/{uuid}`
- `/attachments/{uuid}`
The major work in this PR was to refactoring the existing authentication methods so that "path based matching" that they were currently doing was no longer required, as I didn't want to introduce that into Authorized Integrations. All the path based matching is removed in this PR, and authentication methods are enabled entirely by the middleware applied to their endpoints.
## 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/12776
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
|
||
|
Mathieu Fenniak
|
48218c654b |
feat: authorized integrations DB models and authentication implementation (#12261)
Authorized Integrations is a new feature to allow users to define external systems which can generate JSON Web Tokens (JWTs) that Forgejo will trust in order to perform API access on behalf of that user. This is an authentication mechanism that requires zero preconfiguration of shared secrets, and instead establishes trust through short-lived secrets (JWTs) that are signed by the issuer, signatures are validated by comparison with published public keys, and a public-keys retrieved through well-known HTTP endpoints secured with TLS verification. The primary goal of Authorized Integrations is to support a mechanism for Forgejo Actions to receive elevated, but controlled, additional access to Forgejo. More details as to what the end result will look like are available in the [design proposal](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-13268004) on #3571. This PR adds the core database storage and authentication verification for Authorized Integrations, with these capabilities: - An Authorized Integration is resolved by a unique key of an "issuer" and an "audience". The value of "issuer" is defined by the remote integration, and the value of "audience" will incorporate a unique identifier generated by Forgejo. - Example issuer: `https://token.actions.githubusercontent.com/` is the issuer for GitHub JWTs - Example audience: `https://forgejo.example.org/-/mfenniak/authorized-integration/6cc55ba0` is the expected format for a random audience field that Forgejo will generate. - JWTs can contain any number of claims, which are represented as a JSON object; Forgejo can validate these with a flexible policy. - eg. a claim may be `{"sub": "repo:coolguy/forgejo-runner-testrepo:pull_request"}` indicating that an OIDC token was received from an Actions execution in a specific repo on a specific event. - Authorized Integrations support a `ClaimRules` system which allows claim equal, glob, and nested object inspection. - `{"claim":"sub","comparison":"eq","value":"repo:mfenniak/forgejo-runner-testrepo:pull_request"}` -- would validate that `sub` exactly equals the specific value - `{"claim":"sub","comparison":"glob","value":"repo:mfenniak/forgejo-runner-testrepo:*"}` -- would validate that `sub` matches the given string prefix but allow any event - When a JWT is received on an incoming API call, Forgejo retrieves the Authorized Integration from the DB (if present), validates the token signature against a remote JWKS, validates the claims, and grants API access as the user with a permission scope defined on the Authorized Integration. In addition to the unit testing provided here, this PR has been manually integration tested against three JWT issuing systems: Forgejo Actions, GitHub Actions, and AWS STS GetWebIdentityToken. Careful consideration has been made of these security concerns: - SSRF attacks against Forgejo are prevented by: - having a blocklist on remote HTTP validation requests which prevent access to internal network resources, - ensuring that authorized integrations are created by users with matching issuers, before attempting to validate tokens - Resource utilization attacks against Forgejo are reduced by limiting the possible size of external metadata requests; when fetching `/.well-known/openid-configuration` and `jkws_uri`'s from remote, untrusted servers, a maximum response size of 16 kB is enforced - Only well-known secure assymmetric JWT signing algorithms are supported -- in particular, the sketchy `none` JWT algorithm isn't supported. - JWT validation is covered by extensive unit tests, covering validation of all JWT timestamps, validation of the issuers, validation of the issuer's documented supported signing algorithms. This PR serves as a core, and many enhancements are required for this to be a usable system for users. ## 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... - [ ] `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. - Documentation updates for new config entries will be authored. - [ ] 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. - Marking not visible as there's no mechanism to interact with this backend yet. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12261 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
ef5479af71 |
refactor: split "basic" and "oauth2" authentication impl into smaller single-purpose components (#12236)
Forgejo's `basic` and `oauth2` authentication methods perform five distinct types of authentication:
- Username and password authentication
- Personal access tokens
- OAuth2 access tokens
- Forgejo Action's `${{ forgejo.token }}` -- task-based static tokens
- Forgejo Action's `${{ env.ACTIONS_RUNTIME_TOKEN }}` JWT, which is the authentication method used for `upload-artifact` (mirroring GitHub's implementation)
`basic` and `oauth2` both supported almost all of these methods, resulting in quite a bit of code duplication between them. This PR splits personal access tokens into `access_token.go`, Action's task-based tokens into `action_task_token.go`, and Action's JWT tokens into `action_runtime_token.go`.
**Note:** There is one peculiar side-effect that is worth discussing. Previously, `Authorization: Basic ...` was handled by one complex code path in basic.go, and `Authorization: Bearer ...` was handled by another in oauth2.go, and if authorization failed and a 401 was returned, a single error message would be returned to the user. Now, as multiple authorization methods may look at `Authorization: Basic ...` and provide their own reason why authorization didn't work, a 401 response has multiple reasons for a lack of authorization listed:
```
401 Unauthorized
...
failure to authenticate with oauth2 access token: not a JWT
Basic authorization is not allowed while having security keys enrolled
access token does not exist [sha: notpassword]
task with token "notpassword": resource does not exist
```
A couple tests have been adapted to check that the result contains their expected response, rather than is equal-to or prefixed-with their expected result. This is caused by the "auth group" joining together any "invalid credentials" errors, and, to a certain extent it is useful to understand why the authorization request failed. But it's a bit obscure as well.
## 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.
- Relying on integration testing for regression checks.
- 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/12236
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
|
||
|
Mathieu Fenniak
|
9f7533c1f1 |
refactor: clarify four different outputs that authentication methods provide (#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. ## 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. - Relying on existing test suite, with changes for any compile errors -- the next refactor will simplify the auth methods so that they can be unit tested easily. - 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/12231 Reviewed-by: Gusted <gusted@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
1ddd5faa5c |
refactor: change authentication to return structured data (#12202)
Currently authentication methods return information in two forms: they return who was authenticated as a `*user_model.User`, and then they insert key-values into `ctx.Data` which has critical impact on how the authenticated request is treated. This PR changes the authentication methods to return structured data in the form of an `AuthenticationResult`, with all the key-value information in `ctx.Data` being moved into methods on the `AuthenticationResult` interface. Authentication workflows in Forgejo are a real mess. This is the first step in trying to clean it up and make the code predictable and reasonable, and is both follow-up work that was identified from the repo-specific access tokens (where the `"ApiTokenReducer"` key-value was added), and is pre-requisite work to future JWT enhancements that are [being discussed](https://codeberg.org/forgejo/forgejo/issues/3571#issuecomment-13268004). ## 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. - All changes, at least in theory, are refactors of existing logic and are not expected to have functional deviations -- existing regression tests are the only planned testing. - 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/12202 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> |
||
|
Mathieu Fenniak
|
99984dac4d |
feat: remove admin-level permissions from repo-specific & public-only access tokens (#11468)
This PR is part of a series (#11311). If the user authenticating to an API call is a Forgejo site administrator, or a Forgejo repo administrator, a wide variety of permission and ownership checks in the API are either bypassed, or are bypassable. If a user has created an access token with restricted resources, I understand the intent of the user is to create a token which has a layer of risk reduction in the event that the token is lost/leaked to an attacker. For this reason, it makes sense to me that restricted scope access tokens shouldn't inherit the owner's administrator access. My intent is that repo-specific access tokens [will only be able to access specific authorization scopes](https://codeberg.org/forgejo/design/issues/50#issuecomment-11093951), probably: `repository:read`, `repository:write`, `issue:read`, `issue:write`, (`organization:read` / `user:read` maybe). This means that *most* admin access is not intended to be affected by this because repo-specific access tokens won't have, for example, `admin:write` scope. However, administrative access still grants elevated permissions in some areas that are relevant to these scopes, and need to be restricted: - The `?sudo=otheruser` query parameter allows site administrators to impersonate other users in the API. - Repository management rules are different for a site administrator, allowing them to create repos for another user, create repos in another organization, migrate a repository to an arbitrary owner, and transfer a repository to a prviate organization. - Administrators have access to extra data through some APIs which would be in scope: the detailed configuration of branch protection rules, the some details of repository deploy keys (which repo, and which scope -- seems odd), (user:read -- user SSH keys, activity feeds of private users, user profiles of private users, user webhook configurations). - Pull request reviews have additional perms for repo administrators, including the ability to dismiss PR reviews, delete PR reviews, and view draft PR reviews. - Repo admins and site admins can comment on locked issues, and related to comments can edit or delete other user's comments and attachments. - Repo admins can manage and view logged time on behalf of other users. A handful of these permissions may make sense for repo-specific access tokens, but most of them clearly exceed the risk that would be expected from creating a limited scope access token. I'd generally prefer to take a restrictive approach, and we can relax it if real-world use-cases come in -- users will have a workaround of creating an access token without repo-specific restrictions if they are blocked from needed access. **Breaking:** The administration restrictions introduced in this PR affect both repo-specific access tokens, and existing public-only access tokens. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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... - [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 - [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. - Although repo-specific access tokens are not yet exposed to end users, the breaking changes to public-only tokens will be visible to users and require release notes. - [ ] 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/11468 Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org> Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net> Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net> |
||
|
Mathieu Fenniak
|
635f13a07e | feat: add APIContext.Reducer computed from access token | ||
|
zokki
|
d6838462b8 |
feat: Global 2FA enforcement (#8753)
resolves #8549 This PR add a config to enforce 2FA for the whole Forgejo instance. It can be configured to `none`, `admin` or `all`. A user who is required to enable 2FA is like a disabled user. He can only see the `/user/settings/security`-Page to enable 2FA, this should be similar to a user which needs to change his password. Also api and git-commands are not allowed. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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 - 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 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. I will do it, if the general idea of this PR is a good feature. ### Release notes - [ ] I do not want this change to show in the release notes. - [x] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. <!--start release-notes-assistant--> ## Release notes <!--URL:https://codeberg.org/forgejo/forgejo--> - Security features - [PR](https://codeberg.org/forgejo/forgejo/pulls/8753): <!--number 8753 --><!--line 0 --><!--description R2xvYmFsIDJGQSBlbmZvcmNlbWVudA==-->Global 2FA enforcement<!--description--> <!--end release-notes-assistant--> Co-authored-by: 0ko <0ko@noreply.codeberg.org> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8753 Reviewed-by: 0ko <0ko@noreply.codeberg.org> Reviewed-by: Ellen Εμιλία Άννα Zscheile <fogti@noreply.codeberg.org> Reviewed-by: Gusted <gusted@noreply.codeberg.org> Co-authored-by: zokki <zokki.softwareschmiede@gmail.com> Co-committed-by: zokki <zokki.softwareschmiede@gmail.com> |
||
|
Michael Kriese
|
57148eb1e8 |
fix: query token auth version mismatch (#8666)
It's now scheduled for Forgejo v13 see #8633 for more context I used Github Copilot for some auto completion of code. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. 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 - 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 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. - [x] I did not document these changes and I do not expect someone else to do it. ### Release notes - [x] I do not want this change to show in the release notes. - [ ] I want the title to show in the release notes with a link to this pull request. - [ ] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8666 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Michael Kriese <michael.kriese@visualon.de> Co-committed-by: Michael Kriese <michael.kriese@visualon.de> |
||
|
Earl Warren
|
bfa9c89e6f |
Revert "feat: remove API authentication methods that uses the URL query (#7924)" (#8633)
This reverts commit
|
||
|
Gusted
|
b2a3966e64 |
feat: remove API authentication methods that uses the URL query (#7924)
- They have been marked as deprecated since 2023 and adequate warnings have been given about this method being deprecated, remove it for Forgejo v12. - For clarity: the reason they are deprecated is that these methods allow authentication material to be given via a URL query. This results in the authentication material being logged, which is undesired behavior. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7924 Reviewed-by: Beowulf <beowulf@beocode.eu> Reviewed-by: Michael Kriese <michael.kriese@gmx.de> Co-authored-by: Gusted <postmaster@gusted.xyz> Co-committed-by: Gusted <postmaster@gusted.xyz> |
||
|
Gusted
|
2457f5ff22 |
chore: branding import path (#7337)
- Massive replacement of changing `code.gitea.io/gitea` to `forgejo.org`. - Resolves forgejo/discussions#258 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7337 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Reviewed-by: Michael Kriese <michael.kriese@gmx.de> Reviewed-by: Beowulf <beowulf@beocode.eu> Reviewed-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net> Co-authored-by: Gusted <postmaster@gusted.xyz> Co-committed-by: Gusted <postmaster@gusted.xyz> |
||
|
Otto Richter
|
9dea54a9d6 |
Drop SSPI auth support and more Windows files (#7148)
## Dropping SSPI auth support SSPI authentication relied on Microsoft Windows support, removal started in https://codeberg.org/forgejo/forgejo/pulls/5353, because it was broken anyway. We have no knowledge of any users using SSPI authentication. However, if you somehow managed to run Forgejo on Windows, or want to upgrade from a Gitea version which does, please ensure that you do not use SSPI as an authentication mechanism for user accounts. Feel free to reach out if you need assistance. Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7148 Reviewed-by: Gusted <gusted@noreply.codeberg.org> Reviewed-by: 0ko <0ko@noreply.codeberg.org> Co-authored-by: Otto Richter <otto@codeberg.org> Co-committed-by: Otto Richter <otto@codeberg.org> |
||
|
Ada
|
41676a8634 |
Fix #2512 /api/forgejo/v1/version auth check (#2582)
Add the same auth check and middlewares as the /v1/ API. It require to export some variable from /v1 API, i am not sure if is the correct way to do Co-authored-by: oliverpool <git@olivier.pfad.fr> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2582 Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org> Reviewed-by: Gusted <gusted@noreply.codeberg.org> Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Co-authored-by: Ada <ada@gnous.eu> Co-committed-by: Ada <ada@gnous.eu> |