Jason Song [Thu, 1 Aug 2024 09:04:04 +0000 (17:04 +0800)]
Clarify Actions resources ownership (#31724)
Fix #31707.
Also related to #31715.
Some Actions resources could has different types of ownership. It could
be:
- global: all repos and orgs/users can use it.
- org/user level: only the org/user can use it.
- repo level: only the repo can use it.
There are two ways to distinguish org/user level from repo level:
1. `{owner_id: 1, repo_id: 2}` for repo level, and `{owner_id: 1,
repo_id: 0}` for org level.
2. `{owner_id: 0, repo_id: 2}` for repo level, and `{owner_id: 1,
repo_id: 0}` for org level.
The first way seems more reasonable, but it may not be true. The point
is that although a resource, like a runner, belongs to a repo (it can be
used by the repo), the runner doesn't belong to the repo's org (other
repos in the same org cannot use the runner). So, the second method
makes more sense.
And the first way is not user-friendly to query, we must set the repo id
to zero to avoid wrong results.
So, #31715 should be right. And the most simple way to fix #31707 is
just:
However, it is quite intuitive to set both owner id and repo id since
the repo belongs to the owner. So I prefer to be compatible with it. If
we get both owner id and repo id not zero when creating or finding, it's
very clear that the caller want one with repo level, but set owner id
accidentally. So it's OK to accept it but fix the owner id to zero.
Jason Song [Wed, 31 Jul 2024 10:29:48 +0000 (18:29 +0800)]
Distinguish LFS object errors to ignore missing objects during migration (#31702)
Fix #31137.
Replace #31623 #31697.
When migrating LFS objects, if there's any object that failed (like some
objects are losted, which is not really critical), Gitea will stop
migrating LFS immediately but treat the migration as successful.
This PR checks the error according to the [LFS api
doc](https://github.com/git-lfs/git-lfs/blob/main/docs/api/batch.md#successful-responses).
> LFS object error codes should match HTTP status codes where possible:
>
> - 404 - The object does not exist on the server.
> - 409 - The specified hash algorithm disagrees with the server's
acceptable options.
> - 410 - The object was removed by the owner.
> - 422 - Validation error.
If the error is `404`, it's safe to ignore it and continue migration.
Otherwise, stop the migration and mark it as failed to ensure data
integrity of LFS objects.
And maybe we should also ignore others errors (maybe `410`? I'm not sure
what's the difference between "does not exist" and "removed by the
owner".), we can add it later when some users report that they have
failed to migrate LFS because of an error which should be ignored.
Hide the "Details" link of commit status when the user cannot access actions (#30156)
Fix #26685
If a commit status comes from Gitea Actions and the user cannot access
the repo's actions unit (the user does not have the permission or the
actions unit is disabled), a 404 page will occur after clicking the
"Details" link. We should hide the "Details" link in this case.
OIDC: case-insensitive comparison for auth scheme `Basic` (#31706)
@kylef pointed out on https://github.com/go-gitea/gitea/pull/31632 that
[RFC7617](https://www.rfc-editor.org/rfc/rfc7617.html#section-2)
mandates case-insensitive comparison of the scheme field `Basic`. #31632
copied a case-sensitive comparison from
https://github.com/go-gitea/gitea/pull/6293. This PR fixes both
comparisons.
The issue only affects OIDC, since the implementation for normal Gitea
endpoints is already correct:
We don't need to have polyfills down to Node v4. Some of our deps have
polyfills, and don't utilize the built-in implementation if available.
While this does decrease our package graph, I haven't been able to
notice any decrease/increase in page load times, although that could
likely be just because it's already pretty fast.
Nolyfill is https://github.com/SukkaW/nolyfill
updates to files generated with:
```shell
npx nolyfill install
npm update
```
Before this is/isn't merged, I'd be appreciative/thankful for other's
insights.
Edit: This isn't due to a specific individual. I am generally supportive
of them and their dedication to backward compatibility. This PR is due
to not needing those imports for our minimum requirements. Please don't
take this PR as commentary on anyone's character.
The introspect endpoint was using the OIDC token itself for
authentication. This fixes it to use basic authentication with the
client ID and secret instead:
* Applications with a valid client ID and secret should be able to
successfully introspect an invalid token, receiving a 200 response
with JSON data that indicates the token is invalid
* Requests with an invalid client ID and secret should not be able
to introspect, even if the token itself is valid
Unlike #31561 (which just future-proofed the current behavior against
future changes to `DISABLE_QUERY_AUTH_TOKEN`), this is a potential
compatibility break (some introspection requests without valid client
IDs that would previously succeed will now fail). Affected deployments
must begin sending a valid HTTP basic authentication header with their
introspection requests, with the username set to a valid client ID and
the password set to the corresponding client secret.
Remove unneccessary uses of `word-break: break-all` (#31637)
Fixes: https://github.com/go-gitea/gitea/issues/31636
1. Issue sidebar topic is disussed in
https://github.com/go-gitea/gitea/issues/31636
2. Org description already has `overflow-wrap: anywhere` to ensure no
overflow.
Carsten Klein [Tue, 16 Jul 2024 22:49:05 +0000 (00:49 +0200)]
Allow searching issues by ID (#31479)
When you are entering a number in the issue search, you likely want the
issue with the given ID (code internal concept: issue index).
As such, when a number is detected, the issue with the corresponding ID
will now be added to the results.
allow synchronizing user status from OAuth2 login providers (#31572)
This leverages the existing `sync_external_users` cron job to
synchronize the `IsActive` flag on users who use an OAuth2 provider set
to synchronize. This synchronization is done by checking for expired
access tokens, and using the stored refresh token to request a new
access token. If the response back from the OAuth2 provider is the
`invalid_grant` error code, the user is marked as inactive. However, the
user is able to reactivate their account by logging in the web browser
through their OAuth2 flow.
Also changed to support this is that a linked `ExternalLoginUser` is
always created upon a login or signup via OAuth2.
### Notes on updating permissions
Ideally, we would also refresh permissions from the configured OAuth
provider (e.g., admin, restricted and group mappings) to match the
implementation of LDAP. However, the OAuth library used for this `goth`,
doesn't seem to support issuing a session via refresh tokens. The
interface provides a [`RefreshToken`
method](https://github.com/markbates/goth/blob/master/provider.go#L20),
but the returned `oauth.Token` doesn't implement the `goth.Session` we
would need to call `FetchUser`. Due to specific implementations, we
would need to build a compatibility function for every provider, since
they cast to concrete types (e.g.
[Azure](https://github.com/markbates/goth/blob/master/providers/azureadv2/azureadv2.go#L132))
1. Fixed border-radius
2. Monaco ignores the alpha channel on the shadow color, introduce
`color-shadow-opaque`
3. Remove scrollbar color which follows
https://github.com/go-gitea/gitea/pull/29800
Before:
<img width="34" alt="Screenshot 2024-07-13 at 15 38 18"
src="https://github.com/user-attachments/assets/042d9bde-6db9-4467-a2a4-8f61ecc773eb">
<img width="35" alt="Screenshot 2024-07-13 at 15 38 31"
src="https://github.com/user-attachments/assets/04146ee0-551c-4ff2-9636-bd119b33595a">
After:
<img width="45" alt="Screenshot 2024-07-13 at 15 38 06"
src="https://github.com/user-attachments/assets/1f58fa5a-1289-4e45-83c9-18ca82a5e266">
<img width="39" alt="Screenshot 2024-07-13 at 21 16 56"
src="https://github.com/user-attachments/assets/e12ebe22-b29b-4798-9f0d-4c100f311562">
Sunny Wan [Thu, 11 Jul 2024 23:23:31 +0000 (19:23 -0400)]
Display app name in the registration email title (#31562)
I changed the title of the registation email from "Welcome to Gitea" to
"Welcome to (appname)". I did this by substituting 'Gitea' in
register_notify to %s and formating the registration title in mail.go. I
changed this for all the languages I could, but I struggled to changed
the translation file for Farsi. I have attached the screenshots of
before and after and the related issue below.
Related issue:
https://github.com/go-gitea/gitea/issues/31108
Before change:
![Screenshot from 2024-07-04
22-32-17](https://github.com/go-gitea/gitea/assets/94445569/4178b51c-1acc-45f4-9750-dff41564a709)
After:
![Screenshot from 2024-07-04
22-32-01](https://github.com/go-gitea/gitea/assets/94445569/9cd7a58d-c0f5-4a3c-a66c-805c55411eaa)
---------
Signed-off-by: Sunny Wan <Sunnywan2020@gmail.com> Co-authored-by: 6543 <6543@obermui.de>
Fix: Allow org team names of length 255 in create team form (#31564)
Gitea 1.22.1 was supposed to allow for team names of length 255 (up from
30) after the following PR was merged in:
https://github.com/go-gitea/gitea/pull/31410. However, the length of
team names was still limited to 30 as described in this issue:
https://github.com/go-gitea/gitea/issues/31554.
One more change to _gitea_ needs to be made to allow for the longer team
names, as there is a 30 character limit here:
https://github.com/go-gitea/gitea/blob/2c92c7c5226e29636a1d47a277130f477fa2037b/services/forms/org.go#L65
Allow disabling authentication related user features (#31535)
We have some instances that only allow using an external authentication
source for authentication. In this case, users changing their email,
password, or linked OpenID connections will not have any effect, and
we'd like to prevent showing that to them to prevent confusion.
Included in this are several changes to support this:
* A new setting to disable user managed authentication credentials
(email, password & OpenID connections)
* A new setting to disable user managed MFA (2FA codes & WebAuthn)
* Fix an issue where some templates had separate logic for determining
if a feature was disabled since it didn't check the globally disabled
features
* Hide more user setting pages in the navbar when their settings aren't
enabled
The build currently seems to work fine without this, but in theory it
should fail because Fomantic is JavaScript. I feel more comfortable
having this loader declared.
Note: I did try using the [combined loader
config](https://github.com/privatenumber/esbuild-loader#-quick-setup)
but when I did that, vue files could not load, so I think this is the
best option.
None of the frontend js/ts files was touched besides these two commands
(edit: no longer true, I touched one file in
https://github.com/go-gitea/gitea/pull/31559/commits/61105d0618e285d97e95044bfb64415f364a4526
because of a deprecation that was not showing before the rename).
`tsc` currently reports 778 errors, so I have disabled it in CI as
planned.
Henry Goodman [Fri, 5 Jul 2024 18:21:56 +0000 (04:21 +1000)]
Allow force push to protected branches (#28086)
Fixes #22722
### Problem
Currently, it is not possible to force push to a branch with branch
protection rules in place. There are often times where this is necessary
(CI workflows/administrative tasks etc).
The current workaround is to rename/remove the branch protection,
perform the force push, and then reinstate the protections.
### Solution
Provide an additional section in the branch protection rules to allow
users to specify which users with push access can also force push to the
branch. The default value of the rule will be set to `Disabled`, and the
UI is intuitive and very similar to the `Push` section.
It is worth noting in this implementation that allowing force push does
not override regular push access, and both will need to be enabled for a
user to force push.
This applies to manual force push to a remote, and also in Gitea UI
updating a PR by rebase (which requires force push)
This modifies the `BranchProtection` API structs to add:
- `enable_force_push bool`
- `enable_force_push_whitelist bool`
- `force_push_whitelist_usernames string[]`
- `force_push_whitelist_teams string[]`
- `force_push_whitelist_deploy_keys bool`
As requested in
https://github.com/go-gitea/gitea/pull/31504#issuecomment-2196196646.
This PR refactor the login page:
![Screenshot from 2024-07-04
19-23-10](https://github.com/go-gitea/gitea/assets/6918444/c45700f4-6747-473c-bdee-2156718a7953)
![Screenshot from 2024-07-04
19-23-21](https://github.com/go-gitea/gitea/assets/6918444/b1bf71cf-85f9-4517-a409-cc6d72e6af8f)
![Screenshot from 2024-06-30
09-35-20](https://github.com/go-gitea/gitea/assets/6918444/728cc37e-0cca-4883-afec-a43663d2c666)
# Changes
- [x] use separate box for passkey login and go to registration
- [x] move forgot passoword next to password label
- [x] fix password required label `*` and padding
- [x] remove tabs from login page
Fix slow patch checking with commits that add or remove many files (#31548)
Running git update-index for every individual file is slow, so add and
remove everything with a single git command.
When such a big commit lands in the default branch, it could cause PR
creation and patch checking for all open PRs to be slow, or time out
entirely. For example, a commit that removes 1383 files was measured to
take more than 60 seconds and timed out. With this change checking took
about a second.
This is related to #27967, though this will not help with commits that
change many lines in few files.
Add typescript guideline and typescript-specific eslint plugins and fix issues (#31521)
1. Add some general guidelines how to write our typescript code
2. Add `@typescript-eslint/eslint-plugin`, general typescript rules
3. Add `eslint-plugin-deprecation` to detect deprecated code
4. Fix all new lint issues that came up
silverwind [Fri, 28 Jun 2024 21:29:15 +0000 (23:29 +0200)]
Always use HTML attributes for avatar size (#31509)
Many avatars were rendered in HTML with certain width/height but then
resized again in CSS. This was pointless so I removed all these cases
and made the HTML size match the previous render size.
Also did a few CSS cleanups in the tribute rendering:
silverwind [Fri, 28 Jun 2024 16:15:51 +0000 (18:15 +0200)]
Add initial typescript config and use it for eslint,vitest,playwright (#31186)
This enables eslint to use the typescript parser and resolver which
brings some benefits that eslint rules now have type information
available and a tsconfig.json is required for the upcoming typescript
migration as well. Notable changes done:
- Add typescript parser and resolver
- Move the vue-specific config into the root file
- Enable `vue-scoped-css/enforce-style-type` rule, there was only one
violation and I added a inline disable there.
- Fix new lint errors that were detected because of the parser change
- Update `i/no-unresolved` to remove now-unnecessary workaround for the
resolver
- Disable `i/no-named-as-default` as it seems to raise bogus issues in
the webpack config
- Change vitest config to typescript
- Change playwright config to typescript
- Add `eslint-plugin-playwright` and fix issues
- Add `tsc` linting to `make lint-js`
Royce Remer [Fri, 28 Jun 2024 08:42:57 +0000 (01:42 -0700)]
Support legacy _links LFS batch responses (#31513)
Support legacy _links LFS batch response.
Fixes #31512.
This is backwards-compatible change to the LFS client so that, upon
mirroring from an upstream which has a batch api, it can download
objects whether the responses contain the `_links` field or its
successor the `actions` field. When Gitea must fallback to the legacy
`_links` field a logline is emitted at INFO level which looks like this:
```
...s/lfs/http_client.go:188:performOperation() [I] <LFSPointer ee95d0a27ccdfc7c12516d4f80dcf144a5eaf10d0461d282a7206390635cdbee:160> is using a deprecated batch schema response!
```
I've only run `test-backend` with this code, but added a new test to
cover this case. Additionally I have a fork with this change deployed
which I've confirmed syncs LFS from Gitea<-Artifactory (which has legacy
`_links`) as well as from Gitea<-Gitea (which has the modern `actions`).
silverwind [Fri, 28 Jun 2024 05:59:22 +0000 (07:59 +0200)]
Fix JS error with disabled attachment and easymde (#31511)
Not sure if this is a regression from
https://github.com/go-gitea/gitea/pull/30513, but when attachments are
disabled, `this.dropzone` is null and the code had failed in
`initEasyMDEPaste` trying to access `dropzoneEl.dropzone`.
Tyrone Yeh [Thu, 27 Jun 2024 09:31:49 +0000 (17:31 +0800)]
Improve attachment upload methods (#30513)
* Use dropzone to handle file uploading for all cases, including pasting
and dragging
* Merge duplicate code, use consistent behavior for link generating
CyberFlame [Tue, 25 Jun 2024 14:54:18 +0000 (02:54 +1200)]
use correct l10n string (#31487)
Uses the correct string for searching - this is what it looks like prior
to the change:
![image](https://github.com/go-gitea/gitea/assets/24910512/38519825-c347-44d6-85d4-6fa3c71ddb7c)
(observe how the top box has "Search teams" even though collaborator
would be user
The overflow menu button was incorrectly included in the measurement of
the width of the items. As a result, it could get stuck in a loop
alternating between different measurements as the button appears and
disappears.
Kemal Zebari [Sun, 23 Jun 2024 18:41:01 +0000 (11:41 -0700)]
Disable issue/PR comment button given empty input (#31463)
Given an empty issue/PR comment, the comment history would not be
updated if the user were to submit it. Therefore, it would make since to
just disable the comment button when the text editor is empty.
This is inline with what GitHub does when given empty text editor input.