From issue https://github.com/go-gitea/gitea/issues/27314
When act_runner in `host` mode on Windows. `upload_artifact@v3` actions
use `path.join` to generate `itemPath` params when uploading artifact
chunk. `itemPath` is encoded as `${artifact_name}\${artifact_path}`.
<del>It's twice query escaped from ${artifact_name}/${artifact_path}
that joined by Windows slash \.</del>
**So we need convert Windows slash to linux**.
In https://github.com/go-gitea/gitea/issues/27314, runner shows logs
from `upload_artifact@v3` like with `%255C`:
```
[artifact-cases/test-artifact-cases] | ::error::Unexpected response. Unable to upload chunk to http://192.168.31.230:3000/api/actions_pipeline/_apis/pipelines/workflows/6/artifacts/34d628a422db9367c869d3fb36be81f5/upload?itemPath=more-files%255Css.json
```
But in gitea server at the same time, But shows `%5C`
```
2023/10/27 19:29:51 ...eb/routing/logger.go:102:func1() [I] router: completed PUT /api/actions_pipeline/_apis/pipelines/workflows/6/artifacts/34d628a422db9367c869d3fb36be81f5/upload?itemPath=more-files%5Css.json for 192.168.31.230:55340, 400 Bad Request in 17.6ms @ <autogenerated>:1(actions.artifactRoutes.uploadArtifact-fm)
```
I found `%255C` is escaped by
`https://github.com/actions/upload-artifact/blob/main/dist/index.js#L2329`.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Currently this feature is only available to admins, but there is no
clear reason why. If a user can actually merge pull requests, then this
seems fine as well.
This is useful in situations where direct pushes to the repository are
commonly done by developers.
---------
Co-authored-by: delvh <dev.lh@web.de>
Hello there,
Cargo Index over HTTP is now prefered over git for package updates: we
should not force users who do not need the GIT repo to have the repo
created/updated on each publish (it can still be created in the packages
settings).
The current behavior when publishing is to check if the repo exist and
create it on the fly if not, then update it's content.
Cargo HTTP Index does not rely on the repo itself so this will be
useless for everyone not using the git protocol for cargo registry.
This PR only disable the creation on the fly of the repo when publishing
a crate.
This is linked to #26844 (error 500 when trying to publish a crate if
user is missing write access to the repo) because it's now optional.
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Fixes #27598
In #27080, the logic for the tokens endpoints were updated to allow
admins to create and view tokens in other accounts. However, the same
functionality was not added to the DELETE endpoint. This PR makes the
DELETE endpoint function the same as the other token endpoints and adds unit tests
Closes #27455
> The mechanism responsible for long-term authentication (the 'remember
me' cookie) uses a weak construction technique. It will hash the user's
hashed password and the rands value; it will then call the secure cookie
code, which will encrypt the user's name with the computed hash. If one
were able to dump the database, they could extract those two values to
rebuild that cookie and impersonate a user. That vulnerability exists
from the date the dump was obtained until a user changed their password.
>
> To fix this security issue, the cookie could be created and verified
using a different technique such as the one explained at
https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#secure-remember-me-cookies.
The PR removes the now obsolete setting `COOKIE_USERNAME`.
1. Dropzone attachment removal, pretty simple replacement
2. Image diff: The previous code fetched every image twice, once via
`img[src]` and once via `$.ajax`. Now it's only fetched once and a
second time only when necessary. The image diff code was partially
rewritten.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
storageHandler() is written as a middleware but is used as an endpoint
handler, and thus `next` is actually `nil`, which causes a null pointer
dereference when a request URL does not match the pattern (where it
calls `next.ServerHTTP()`).
Example CURL command to trigger the panic:
```
curl -I "http://yourhost/gitea//avatars/a"
```
Fixes #27409
---
Note: the diff looks big but it's actually a small change - all I did
was to remove the outer closure (and one level of indentation) ~and
removed the HTTP method and pattern checks as they seem redundant
because go-chi already does those checks~. You might want to check "Hide
whitespace" when reviewing it.
Alternative solution (a bit simpler): append `, misc.DummyOK` to the
route declarations that utilize `storageHandler()` - this makes it
return an empty response when the URL is invalid. I've tested this one
and it works too. Or maybe it would be better to return a 400 error in
that case (?)
This pull request is a minor code cleanup.
From the Go specification (https://go.dev/ref/spec#For_range):
> "1. For a nil slice, the number of iterations is 0."
> "3. If the map is nil, the number of iterations is 0."
`len` returns 0 if the slice or map is nil
(https://pkg.go.dev/builtin#len). Therefore, checking `len(v) > 0`
before a loop is unnecessary.
---
At the time of writing this pull request, there wasn't a lint rule that
catches these issues. The closest I could find is
https://staticcheck.dev/docs/checks/#S103
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
This PR reduces the complexity of the system setting system.
It only needs one line to introduce a new option, and the option can be
used anywhere out-of-box.
It is still high-performant (and more performant) because the config
values are cached in the config system.
Part of #27065
This PR touches functions used in templates. As templates are not static
typed, errors are harder to find, but I hope I catch it all. I think
some tests from other persons do not hurt.
Follow #23465 and #25624
This PR introduces the following improvements:
- We do not need to call `GetTags` to get tags because tags have been
loaded by `RepoAssignment`
ef90fdbd1d/modules/context/repo.go (L663-L668)
- Similarly, the number of tags and releases also have been loaded by
`RepoAssignment`, so the related code has been removed from the
handlers. The query condition of `GetReleaseCountByRepoID` in
`RepoAssignment` has been changed to include draft releases.
ef90fdbd1d/modules/context/repo.go (L538-L551)
- `releasesOrTags` function has been removed. The code for rendering
releases list and tags list moved to `Releases` and `TagList`
respectively.
This PR removed `unittest.MainTest` the second parameter
`TestOptions.GiteaRoot`. Now it detects the root directory by current
working directory.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Partially Fix #25041
This PR redefined the meaning of column `is_active` in table
`action_runner_token`.
Before this PR, `is_active` means whether it has been used by any
runner. If it's true, other runner cannot use it to register again.
In this PR, `is_active` means whether it's validated to be used to
register runner. And if it's true, then it can be used to register
runners until it become false. When creating a new `is_active` register
token, any previous tokens will be set `is_active` to false.
Fixes https://github.com/go-gitea/gitea/issues/27136.
This does the following for Monaco's EOL setting:
1. Use editorconfig setting if present
2. Use the file's dominant line ending as detected by monaco, which uses
LF for empty file
Beginning since 2af30f715e, Gitea has a
500 error when visiting a user profile with `?tab=overview` in the URL
when the user doesn't have a `.profile/README.md`, because the backend
code assumes that if the tab is overview a profile repository must
exist, and checks that the repository is nil aren't done.
In this PR I treat `?tab=overview` the same as if no tab is set in the
URL, which corrects this behaviour- Now, when visiting `?tab=overview`,
if `.profile/README.md` exists on that user's profile it'll show that as
it should, otherwise it'll show the repositories tab.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
- Use the correct total amount for pagination. Thereby correctly show
the pagination bare when there's more than one page of
followers/followings.
Refs: https://codeberg.org/forgejo/forgejo/pulls/1477
(cherry picked from commit c1a136318b)
Co-authored-by: Gusted <postmaster@gusted.xyz>
Closes #26329
This PR adds the ability to ignore revisions specified in the
`.git-blame-ignore-revs` file in the root of the repository.
The banner is displayed in this case. I intentionally did not add a UI
way to bypass the ignore file (same behaviour as Github) but you can add
`?bypass-blame-ignore=true` to the url manually.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR adds a new field `RemoteAddress` to both mirror types which
contains the sanitized remote address for easier (database) access to
that information. Will be used in the audit PR if merged.
Part of #27065
This reduces the usage of `db.DefaultContext`. I think I've got enough
files for the first PR. When this is merged, I will continue working on
this.
Considering how many files this PR affect, I hope it won't take to long
to merge, so I don't end up in the merge conflict hell.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix #26723
Add `ChangeDefaultBranch` to the `notifier` interface and implement it
in `indexerNotifier`. So when changing the default branch,
`indexerNotifier` sends a message to the `indexer queue` to update the
index.
---------
Co-authored-by: techknowlogick <matti@mdranta.net>
Most middleware throw a 404 in case something is not found e.g. a Repo
that is not existing. But most API endpoints don't include the 404
response in their documentation. This PR changes this.
Unfortunately, when a system setting hasn't been stored in the database,
it cannot be cached.
Meanwhile, this PR also uses context cache for push email avatar display
which should avoid to read user table via email address again and again.
According to my local test, this should reduce dashboard elapsed time
from 150ms -> 80ms .
This feature was removed by #22219 to avoid possible CSRF attack.
This PR takes reverseproxy auth for API back but with default disabled.
To prevent possbile CSRF attack, the responsibility will be the
reverseproxy but not Gitea itself.
For those want to enable this `ENABLE_REVERSE_PROXY_AUTHENTICATION_API`,
they should know what they are doing.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Currently, Artifact does not have an expiration and automatic cleanup
mechanism, and this feature needs to be added. It contains the following
key points:
- [x] add global artifact retention days option in config file. Default
value is 90 days.
- [x] add cron task to clean up expired artifacts. It should run once a
day.
- [x] support custom retention period from `retention-days: 5` in
`upload-artifact@v3`.
- [x] artifacts link in actions view should be non-clickable text when
expired.
They currently throw a Internal Server Error when you use them without a
token. Now they correctly return a `token is required` error.
This is no security issue. If you use this endpoints with a token that
don't have the correct permission, you get the correct error. This is
not affected by this PR.
- Add routes for creating or updating a user's actions secrets in
`routers/api/v1/api.go`
- Add a new file `routers/api/v1/user/action.go` with functions for
creating or updating a user's secrets and deleting a user's secret
- Modify the `templates/swagger/v1_json.tmpl` file to include the routes
for creating or updating a user's secrets and deleting a user's secret
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
## Changes
- Forces flashed error to render immediately when forgot password code
is incorrect or has expired.
- Adds a link back to the `forgot_password` page so that the user can
restart the process (in the event that their link has expired)
Fixes #24944
Since a user with write permissions for issues can add attachments to an
issue via the the web interface, the user should also be able to add
attachments via the API
- Modify the `CreateOrUpdateSecret` function in `api.go` to include a
`Delete` operation for the secret
- Modify the `DeleteOrgSecret` function in `action.go` to include a
`DeleteSecret` operation for the organization
- Modify the `DeleteSecret` function in `action.go` to include a
`DeleteSecret` operation for the repository
- Modify the `v1_json.tmpl` template file to update the `operationId`
and `summary` for the `deleteSecret` operation in both the organization
and repository sections
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Just like `models/unittest`, the testing helper functions should be in a
separate package: `contexttest`
And complete the TODO:
> // TODO: move this function to other packages, because it depends on
"models" package
You can currently visit `{repo}/issues/new` and create a blank issue,
even if it's disabled. This PR fixes this,
Fixes https://codeberg.org/forgejo/forgejo/issues/1356
Co-authored-by: Giteabot <teabot@gitea.io>
This PR implements a proposal to clean up the admin users table by
moving some information out to a separate user details page (which also
displays some additional information).
Other changes:
- move edit user page from `/admin/users/{id}` to
`/admin/users/{id}/edit` -> `/admin/users/{id}` now shows the user
details page
- show if user is instance administrator as a label instead of a
separate column
- separate explore users template into a page- and a shared one, to make
it possible to use it on the user details page
- fix issue where there was no margin between alert message and
following content on admin pages
<details>
<summary>Screenshots</summary>
</details>
Partially resolves #25939
---------
Co-authored-by: Giteabot <teabot@gitea.io>
> ### Description
> If a new branch is pushed, and the repository has a rule that would
require signed commits for the new branch, the commit is rejected with a
500 error regardless of whether it's signed.
>
> When pushing a new branch, the "old" commit is the empty ID
(0000000000000000000000000000000000000000). verifyCommits has no
provision for this and passes an invalid commit range to git rev-list.
Prior to 1.19 this wasn't an issue because only pre-existing individual
branches could be protected.
>
> I was able to reproduce with
[try.gitea.io/CraigTest/test](https://try.gitea.io/CraigTest/test),
which is set up with a blanket rule to require commits on all branches.
Fix #25565
Very thanks to @Craig-Holmquist-NTI for reporting the bug and suggesting
an valid solution!
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
