Backport #39785 by @bircni
The [Gitea VS Code extension](https://gitea.com/gitea/gitea-vscode)
currently signs in through the builtin `tea` OAuth2 application. Gitea
keeps one grant per user and application, so anyone who has already
signed in with the tea CLI gets `a grant exists with different scope`
when the extension requests its own scopes, and sign-in fails
(gitea/gitea-vscode#24).
This adds a dedicated builtin application for the extension, following
the same mechanism as the existing CLI entries:
| | |
|---|---|
| client ID | `75a9ec3e-42b5-40cb-9144-9ea96ecd56a6` |
| config name | `gitea-vscode` |
| display name | `gitea-vscode` |
| redirect URIs | `http://127.0.0.1`, `https://127.0.0.1` (loopback, any
port) |
It is enabled by default via `[oauth2].DEFAULT_APPLICATIONS`. Instances
that set that option explicitly need to add `gitea-vscode` to use it.
The extension will use this client on Gitea >= 28.2.0 and keep falling
back to `tea` on older servers, so this should be backported to v28.
Co-authored-by: bircni <bircni@icloud.com>
This is a prepare and required step for upcoming Gitea Official Mobile
APP which supports login with OAuth2.
The official Gitea mobile app needs the same mechanism. This adds a
builtin application for it:
| | |
|---|---|
| client ID | `b757811a-05c8-4c76-8d74-a5ee3d2073f2` |
| config name | `gitea-app` |
| display name | `Gitea App` |
| redirect URI | `com.gitea.app://oauth/callback` |
Unlike the existing entries, which are CLIs and can therefore use a
loopback `http://127.0.0.1` redirect, a mobile app authorises through a
system browser session (`ASWebAuthenticationSession` on iOS, Custom Tabs
on Android) that can only receive a custom-scheme callback, hence the
custom scheme here.
Fix#29074 (allow to disable all builtin apps) and don't make the doctor
command remove the builtin apps.
By the way, rename refobject and joincond to camel case.
