a3881ffa3d
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: ![Screenshot_20241121_121405](https://github.com/user-attachments/assets/29deaed7-4333-4b02-8898-b822e6f2463e) ![Screenshot_20241121_120211](https://github.com/user-attachments/assets/7a4a4ef7-409c-4116-9d5f-2fe00eb37167) ![Screenshot_20241121_120119](https://github.com/user-attachments/assets/aa52c1a2-212d-4e64-bcdf-7122cee49eb6) ![Screenshot_20241121_120018](https://github.com/user-attachments/assets/9eac318c-e381-4ea9-9e2c-3a3f60319e47) --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com> |
||
---|---|---|
.devcontainer | ||
.gitea | ||
.github | ||
assets | ||
build | ||
cmd | ||
contrib | ||
custom/conf | ||
docker | ||
models | ||
modules | ||
options | ||
public | ||
routers | ||
services | ||
snap | ||
templates | ||
tests | ||
tools | ||
web_src | ||
.air.toml | ||
.changelog.yml | ||
.dockerignore | ||
.editorconfig | ||
.envrc | ||
.eslintrc.yaml | ||
.gitattributes | ||
.gitignore | ||
.gitpod.yml | ||
.golangci.yml | ||
.ignore | ||
.markdownlint.yaml | ||
.npmrc | ||
.spectral.yaml | ||
.yamllint.yaml | ||
BSDmakefile | ||
build.go | ||
CHANGELOG-archived.md | ||
CHANGELOG.md | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
crowdin.yml | ||
DCO | ||
Dockerfile | ||
Dockerfile.rootless | ||
flake.lock | ||
flake.nix | ||
go.mod | ||
go.sum | ||
LICENSE | ||
main.go | ||
MAINTAINERS | ||
Makefile | ||
package-lock.json | ||
package.json | ||
playwright.config.ts | ||
poetry.lock | ||
poetry.toml | ||
pyproject.toml | ||
README_ZH.md | ||
README.md | ||
SECURITY.md | ||
stylelint.config.js | ||
tailwind.config.js | ||
tsconfig.json | ||
updates.config.js | ||
vitest.config.ts | ||
webpack.config.js |
Gitea
Purpose
The goal of this project is to make the easiest, fastest, and most painless way of setting up a self-hosted Git service.
As Gitea is written in Go, it works across all the platforms and architectures that are supported by Go, including Linux, macOS, and Windows on x86, amd64, ARM and PowerPC architectures. This project has been forked from Gogs since November of 2016, but a lot has changed.
For online demonstrations, you can visit demo.gitea.com.
For accessing free Gitea service (with a limited number of repositories), you can visit gitea.com.
To quickly deploy your own dedicated Gitea instance on Gitea Cloud, you can start a free trial at cloud.gitea.com.
Building
From the root of the source tree, run:
TAGS="bindata" make build
or if SQLite support is required:
TAGS="bindata sqlite sqlite_unlock_notify" make build
The build
target is split into two sub-targets:
make backend
which requires Go Stable, the required version is defined in go.mod.make frontend
which requires Node.js LTS or greater.
Internet connectivity is required to download the go and npm modules. When building from the official source tarballs which include pre-built frontend files, the frontend
target will not be triggered, making it possible to build without Node.js.
More info: https://docs.gitea.com/installation/install-from-source
Using
./gitea web
Note
If you're interested in using our APIs, we have experimental support with documentation.
Contributing
Expected workflow is: Fork -> Patch -> Push -> Pull Request
Note
- YOU MUST READ THE CONTRIBUTORS GUIDE BEFORE STARTING TO WORK ON A PULL REQUEST.
- If you have found a vulnerability in the project, please write privately to security@gitea.io. Thanks!
Translating
Translations are done through Crowdin. If you want to translate to a new language ask one of the managers in the Crowdin project to add a new language there.
You can also just create an issue for adding a language or ask on discord on the #translation channel. If you need context or find some translation issues, you can leave a comment on the string or ask on Discord. For general translation questions there is a section in the docs. Currently a bit empty but we hope to fill it as questions pop up.
https://docs.gitea.com/contributing/localization
Further information
For more information and instructions about how to install Gitea, please look at our documentation. If you have questions that are not covered by the documentation, you can get in contact with us on our Discord server or create a post in the discourse forum.
We maintain a list of Gitea-related projects at gitea/awesome-gitea.
The official Gitea CLI is developed at gitea/tea.
Authors
Backers
Thank you to all our backers! 🙏 [Become a backer]
Sponsors
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]
FAQ
How do you pronounce Gitea?
Gitea is pronounced /ɡɪ’ti:/ as in "gi-tea" with a hard g.
Why is this not hosted on a Gitea instance?
We're working on it.
License
This project is licensed under the MIT License. See the LICENSE file for the full license text.
Screenshots
Looking for an overview of the interface? Check it out!