IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This PR removes (almost) all path tricks, and introduces "renderhelper"
package.
Now we can clearly see the rendering behaviors for comment/file/wiki,
more details are in "renderhelper" tests.
Fix#31411 , fix#18592, fix#25632 and maybe more problems. (ps: fix
#32608 by the way)
As per https://vuejs.org/guide/typescript/overview#overview,
typescript's `tsc` does not support importing `.vue` files from `.ts`
files, so we need to use `vue-tsc` which patches in that support. Added
a convenience alias `make tsc` to run it.
Targeting issue #32271
This modification allows native Kubernetes + AWS (EKS) authentication
with the Minio client, to Amazon S3 using the IRSA role assigned to a
Service account by replacing the hard coded reference to the
`DefaultIAMRoleEndpoint` with an optional configurable endpoint.
Internally, Minio's `credentials.IAM` provider implements a discovery
flow for IAM Endpoints if it is not set.
For backwards compatibility:
- We have added a configuration mechanism for an `IamEndpoint` to retain
the unit test safety in `minio_test.go`.
- We believe existing clients will continue to function the same without
needing to provide a new config property since the internals of Minio
client also often resolve to the `http://169.254.169.254` default
endpoint that was being hard coded before
To test, we were able to build a docker image from source and, observe
it choosing the expected IAM endpoint, and see files uploaded via the
client.
This PR rewrites `GetReviewer` function and move it to service layer.
Reviewers should not be watchers, so that this PR removed all watchers
from reviewers. When the repository is under an organization, the pull
request unit read permission will be checked to resolve the bug of
#32394Fix#32394
Resolve#31609
This PR was initiated following my personal research to find the
lightest possible Single Sign-On solution for self-hosted setups. The
existing solutions often seemed too enterprise-oriented, involving many
moving parts and services, demanding significant resources while
promising planetary-scale capabilities. Others were adequate in
supporting basic OAuth2 flows but lacked proper user management
features, such as a change password UI.
Gitea hits the sweet spot for me, provided it supports more granular
access permissions for resources under users who accept the OAuth2
application.
This PR aims to introduce granularity in handling user resources as
nonintrusively and simply as possible. It allows third parties to inform
users about their intent to not ask for the full access and instead
request a specific, reduced scope. If the provided scopes are **only**
the typical ones for OIDC/OAuth2—`openid`, `profile`, `email`, and
`groups`—everything remains unchanged (currently full access to user's
resources). Additionally, this PR supports processing scopes already
introduced with [personal
tokens](https://docs.gitea.com/development/oauth2-provider#scopes) (e.g.
`read:user`, `write:issue`, `read:group`, `write:repository`...)
Personal tokens define scopes around specific resources: user info,
repositories, issues, packages, organizations, notifications,
miscellaneous, admin, and activitypub, with access delineated by read
and/or write permissions.
The initial case I wanted to address was to have Gitea act as an OAuth2
Identity Provider. To achieve that, with this PR, I would only add
`openid public-only` to provide access token to the third party to
authenticate the Gitea's user but no further access to the API and users
resources.
Another example: if a third party wanted to interact solely with Issues,
it would need to add `read:user` (for authorization) and
`read:issue`/`write:issue` to manage Issues.
My approach is based on my understanding of how scopes can be utilized,
supported by examples like [Sample Use Cases: Scopes and
Claims](https://auth0.com/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims)
on auth0.com.
I renamed `CheckOAuthAccessToken` to `GetOAuthAccessTokenScopeAndUserID`
so now it returns AccessTokenScope and user's ID. In the case of
additional scopes in `userIDFromToken` the default `all` would be
reduced to whatever was asked via those scopes. The main difference is
the opportunity to reduce the permissions from `all`, as is currently
the case, to what is provided by the additional scopes described above.
Screenshots:
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
When running e2e tests on flaky networks, gravatar can cause a timeout
and test failures. Turn off, and populate avatars on e2e test suite run
to make them reliable.
We have some actions that leverage the Gitea API that began receiving
401 errors, with a message that the user was not found. These actions
use the `ACTIONS_RUNTIME_TOKEN` env var in the actions job to
authenticate with the Gitea API. The format of this env var in actions
jobs changed with go-gitea/gitea/pull/28885 to be a JWT (with a
corresponding update to `act_runner`) Since it was a JWT, the OAuth
parsing logic attempted to parse it as an OAuth token, and would return
user not found, instead of falling back to look up the running task and
assigning it to the actions user.
Make ACTIONS_RUNTIME_TOKEN in action runners could be used,
attempting to parse Oauth JWTs. The code to parse potential old
`ACTION_RUNTIME_TOKEN` was kept in case someone is running an older
version of act_runner that doesn't support the Actions JWT.
When opening the latest code in **Gitpod** and running `make
lint-backend`, the following error occurs:
```bash
gitpod /workspace/gitea (main) $ make lint-backend
go run github.com/golangci/golangci-lint/cmd/golangci-lint@v1.60.3 run
# internal/profilerecord
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/goarch
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# unicode/utf8
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/coverage/rtcov
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/byteorder
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# cmp
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/itoa
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/race
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/goos
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/unsafeheader
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# unicode
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/godebugs
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/asan
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# math/bits
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/goexperiment
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/msan
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/runtime/atomic
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# sync/atomic
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/runtime/syscall
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# crypto/internal/alias
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# encoding
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# log/internal
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# vendor/golang.org/x/crypto/cryptobyte/asn1
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/golangci/golangci-lint/pkg/exitcodes
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/cpu
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# unicode/utf16
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# container/list
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# crypto/subtle
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/goversion
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# golang.org/x/exp/maps
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/ccojocar/zxcvbn-go/match
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# golang.org/x/exp/constraints
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# golang.org/x/tools/internal/packagesinternal
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/quasilyte/go-ruleguard/dsl/types
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# vendor/golang.org/x/crypto/internal/alias
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/nettrace
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/google/go-cmp/cmp/internal/flags
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/gobwas/glob/util/runes
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# internal/platform
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# crypto/internal/boring/sig
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/quasilyte/gogrep/internal/stdinfo
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/daixiang0/gci/pkg/utils
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/quasilyte/stdinfo
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/Antonboom/testifylint/internal/testify
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# hash/maphash
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# github.com/nunnatsa/ginkgolinter/version
compile: version "go1.23.1" does not match go tool version "go1.22.9"
# google.golang.org/protobuf/internal/flags
compile: version "go1.23.1" does not match go tool version "go1.22.9"
make: *** [Makefile:413: lint-go] Error 1
```
Remove unmaintainable sanitizer rules. No need to add special "class"
regexp rules anymore, use RenderInternal.SafeAttr instead, more details
(and examples) are in the tests
- Move models/GetForks to services/FindForks
- Add doer as a parameter of FindForks to check permissions
- Slight performance optimization for get forks API with batch loading
of repository units
- Add tests for forking repository to organizations
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
By some CI fine tunes (`run tests`), SQLite & MSSQL could complete
in about 12~13 minutes (before > 14), MySQL could complete in 18 minutes
(before: about 23 or even > 30)
Major changes:
1. use tmpfs for MySQL storage
1. run `make test-mysql` instead of `make integration-test-coverage`
because the code coverage is not really used at the moment.
1. refactor testlogger to make it more reliable and be able to report
stuck stacktrace
1. do not requeue failed items when a queue is being flushed (failed
items would keep failing and make flush uncompleted)
1. reduce the file sizes for testing
1. use math ChaCha20 random data instead of crypot/rand (for testing
purpose only)
1. no need to `DeleteRepository` in `TestLinguist`
1. other related refactoring to make code easier to maintain
Since there is a status column in the database, the transaction is
unnecessary when downloading an archive. The transaction is blocking
database operations, especially with SQLite.
Replace #27563
In profiling integration tests, I found a couple places where per-test
overhead could be reduced:
* Avoiding disk IO by synchronizing instead of deleting & copying test
Git repository data. This saves ~100ms per test on my machine
* When flushing queues in `PrintCurrentTest`, invoke `FlushWithContext`
in a parallel.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Many files do not directly depend on jQuery now.
To clarify the usage: use `fomanticQuery` to operate Fomantic
components.
Then developers could focus on removing the remaining jQuery usages by
searching `import $` globally.
21 files now:
```
./components/RepoBranchTagSelector.vue:3:import $ from 'jquery';
./features/admin/common.ts:1:import $ from 'jquery';
./features/admin/emails.ts:1:import $ from 'jquery';
./features/common-button.ts:1:import $ from 'jquery';
./features/comp/ComboMarkdownEditor.ts:3:import $ from 'jquery'; (I am working on it, there will be a new PR)
./features/comp/LabelEdit.ts:1:import $ from 'jquery';
./features/notification.ts:1:import $ from 'jquery';
./features/org-team.ts:1:import $ from 'jquery';
./features/repo-code.ts:1:import $ from 'jquery';
./features/repo-common.ts:1:import $ from 'jquery';
./features/repo-diff.ts:1:import $ from 'jquery';
./features/repo-editor.ts:1:import $ from 'jquery';
./features/repo-issue-content.ts:1:import $ from 'jquery';
./features/repo-issue-list.ts:1:import $ from 'jquery';
./features/repo-issue-sidebar.ts:1:import $ from 'jquery';
./features/repo-issue.ts:1:import $ from 'jquery';
./features/repo-legacy.ts:1:import $ from 'jquery';
./features/repo-new.ts:1:import $ from 'jquery';
./features/repo-projects.ts:1:import $ from 'jquery';
./features/repo-settings.ts:1:import $ from 'jquery';
./features/repo-template.ts:1:import $ from 'jquery';
```
