- Backport of #2696
- Add `form-fetch-action` to indicate that this form POST to an link
that returns JSON and thus should be handled by Javascript code.
- Found by @fnetx
- Regression of https://codeberg.org/forgejo/forgejo/pulls/1793
(cherry picked from commit 9551c1a6f8)
This should fix#2266.
This has apparently be fixed in `main` https://github.com/go-gitea/gitea/pull/27798 (but quite a big PR, which was not backported). I should likely push the test to the main branch as well.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2626
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Backport #29430
Thanks to inferenceus : some sort orders on the "explore/users" page
could list users by their lastlogintime/updatetime.
It leaks user's activity unintentionally. This PR makes that page only
use "supported" sort orders.
Removing the "sort orders" could also be a good solution, while IMO at
the moment keeping the "create time" and "name" orders is also fine, in
case some users would like to find a target user in the search result,
the "sort order" might help.
(cherry picked from commit 2b059f493e46b8b0fb52492623e36a8375cb5fbb)
Backport #29537 by wxiaoguang
This is only a quick fix to make it easier to backport.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 971eab18fa0b29312105df739fba443cf9e84d50)
Backport #29535 by wxiaoguang
* `$referenceUrl`: it is constructed by "Issue.Link", which already has
the "AppSubURL"
* `window.location.href`: AppSubURL could be empty string, so it needs
the trailing slash
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 401cc394d52c6126d3cbca1e1367c4e4da5110f9)
Backport #29470 by @silverwind
Ported the function as-is and added comments so we don't forget about
this in the future.
Fixes: https://github.com/go-gitea/gitea/issues/29462
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 222f93822eb4d03f5001ef665377a115bc27ccb6)
- Backport of #2489
- If the user is searching repositories with an specific topic, adding
any other filter option, such as showing unrelevant repositories or
using another sort Forgejo should remember that 'topic only' was set.
- Adds integration test.
- Resolves#2461
(cherry picked from commit b4360d504c)
- It's possible for reviews to not be assiocated with users, when they
were migrated from another forge instance. In the migration code,
there's no sanitization check for author names, so they could contain
HTML tags and thus needs to be properely escaped.
- Pass `$reviewerName` trough `Escape`.
- On the wiki and revisions page, information is shown about the last
commit that modified that wiki page. This includes the time it was last
edited and by whom. That whole string is not being sanitized (passed
trough `Safe` in the templates), because the last edited bit is
formatted as an HTML element and thus shouldn't be sanitized. The
problem with this is that now `.Author.Name` is not being sanitized.
- This can be exploited, the names of authors and commiters on a Git
commit is user controlled, they can be any value and thus also include
HTML. It's not easy to actually exploit this, as you cannot use the
official git binary to do use, as they actually strip `<` and `>` from
user names (trivia: this behaviour was introduced in the initial commit
of Git). In the integration testing, go-git actually has to generate
this commit as they don't have such restrictions.
- Pass `.Author.Name` trough `Escape` in order to be sanitized.
- Backport of #1805
- https://codeberg.org/forgejo/forgejo/pulls/1473 made that dangerous
actions such as deletion also would need to type in the owner's name.
This was apparently not reflected to the deletion modal for migrations
that failed or were cancelled.
- Resolves#2404
(cherry picked from commit c38dbd6f88)
Follow-up of #2282 and #2296 (which tried to address #2278)
One of the issue with the previous PR is that when a conversation on the Files tab was marked as "resolved", it would fetch all the comments for that line (even the outdated ones, which should not be shown on this page - except when explicitly activated).
To properly fix this, I have changed `FetchCodeCommentsByLine` to `FetchCodeConversation`. Its role is to fetch all comments related to a given (review, path, line) and reverted my changes in the template (which were based on a misunderstanding).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2306
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
Backport #28935 by @silverwind
The `ToUTF8*` functions were stripping BOM, while BOM is actually valid
in UTF8, so the stripping must be optional depending on use case. This
does:
- Add a options struct to all `ToUTF8*` functions, that by default will
strip BOM to preserve existing behaviour
- Remove `ToUTF8` function, it was dead code
- Rename `ToUTF8WithErr` to `ToUTF8`
- Preserve BOM in Monaco Editor
- Remove a unnecessary newline in the textarea value. Browsers did
ignore it, it seems but it's better not to rely on this behaviour.
Fixes: https://github.com/go-gitea/gitea/issues/28743
Related: https://github.com/go-gitea/gitea/issues/6716 which seems to
have once introduced a mechanism that strips and re-adds the BOM, but
from what I can tell, this mechanism was removed at some point after
that PR.
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit b8e6cffd31)
Backport #26745Fixes#26548
This PR refactors the rendering of markup links. The old code uses
`strings.Replace` to change some urls while the new code uses more
context to decide which link should be generated.
The added tests should ensure the same output for the old and new
behaviour (besides the bug).
We may need to refactor the rendering a bit more to make it clear how
the different helper methods render the input string. There are lots of
options (resolve links / images / mentions / git hashes / emojis / ...)
but you don't really know what helper uses which options. For example,
we currently support images in the user description which should not be
allowed I think:
<details>
<summary>Profile</summary>
https://try.gitea.io/KN4CK3R
</details>
(cherry picked from commit 022552d5b6)
Backport #28588 by @yardenshoham
It included the hours, minutes, and seconds. By removing these, the date
renders correctly.
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: Yarden Shoham <git@yardenshoham.com>
(cherry picked from commit 564068aa99)
- Backport of #2100
- Make the reference URL in the "Reference in New issue" feature
absolute again as it wouldn't render as a link otherwise.
- Adds integration test.
- Regression by 769be877f2
- Resolves#2012
(cherry picked from commit c74bae2897)
- Backport of #2094
- It's possible that `PageIsDiff` is set but not `Commit` resulting in a
NPE in the template. This can happen when the requested commit doesn't exist.
- Regression of c802c46a9b &
5743d7cb5b
- Added 'hacky' integration test.
(cherry picked from commit 8db2d5e4a7)
Backport #28576 by wxiaoguang
Regression of #28454 . Now the string is escaped HTML, so it doesn't
need `| Safe`.
Fix#28575
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit acc8100d47)
Backport #28520 by @framitdavid
There is an accessibility issue in the interface when attempting to
delete a repository. When I click on "Delete repository," a dialog box
appears, requiring confirmation to proceed with the repository deletion.
However, when I press the "Repo name" label, the wrong input field gains
focus. The focused field is located behind the dialog and is intended
for renaming the repository.
I am submitting these pull requests to ensure that the correct input
field is focused when the user clicks on the label. This change will
also facilitate the writing of tests using Playwright or Testing Library
to retrieve elements based on roles. This PR will also improve
acessibility of this area.
Co-authored-by: David Øvrelid <46874830+framitdavid@users.noreply.github.com>
(cherry picked from commit 932e282e15)
Backport #28491 by @appleboy
- Modify the `Password` field in `CreateUserOption` struct to remove the
`Required` tag
- Update the `v1_json.tmpl` template to include the `email` field and
remove the `password` field
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-authored-by: Bo-Yi Wu <appleboy.tw@gmail.com>
(cherry picked from commit 411310d698)
Backport #28454 (the only conflict is caused by some comments)
* Close#24483
* Close#28123
* Close#23682
* Close#23149
(cherry picked from commit a3f403f438)
Conflicts:
modules/setting/ui.go
trivial context conflict
It shows warnings although the setting is not set, this will surely be
fixed later but there is no sense in spaming the users right now. This
revert can be discarded when another fix lands in v1.21.
su -c "forgejo admin user generate-access-token -u root --raw --scopes 'all,sudo'" git
2023/12/12 15:54:45 .../setting/security.go:166:loadSecurityFrom() [W] Enabling Query API Auth tokens is not recommended. DISABLE_QUERY_AUTH_TOKEN will default to true in gitea 1.23 and will be removed in gitea 1.24.
This reverts commit 0e3a5abb69.
Conflicts:
routers/api/v1/api.go
Backport #28390 by @jackHay22
## Changes
- Add deprecation warning to `Token` and `AccessToken` authentication
methods in swagger.
- Add deprecation warning header to API response. Example:
```
HTTP/1.1 200 OK
...
Warning: token and access_token API authentication is deprecated
...
```
- Add setting `DISABLE_QUERY_AUTH_TOKEN` to reject query string auth
tokens entirely. Default is `false`
## Next steps
- `DISABLE_QUERY_AUTH_TOKEN` should be true in a subsequent release and
the methods should be removed in swagger
- `DISABLE_QUERY_AUTH_TOKEN` should be removed and the implementation of
the auth methods in question should be removed
## Open questions
- Should there be further changes to the swagger documentation?
Deprecation is not yet supported for security definitions (coming in
[OpenAPI Spec version
3.2.0](https://github.com/OAI/OpenAPI-Specification/issues/2506))
- Should the API router logger sanitize urls that use `token` or
`access_token`? (This is obviously an insufficient solution on its own)
Co-authored-by: Jack Hay <jack@allspice.io>
Co-authored-by: delvh <dev.lh@web.de>
(cherry picked from commit f144521aea)
