Reminder: the migration is run via integration tests as explained
in the commit "[DB] run all Forgejo migrations in integration tests"
(cherry picked from commit 4accf7443c)
- The current architecture is inherently insecure, because you can
construct the 'secret' cookie value with values that are available in
the database. Thus provides zero protection when a database is
dumped/leaked.
- This patch implements a new architecture that's inspired from: [Paragonie Initiative](https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#secure-remember-me-cookies).
- Integration testing is added to ensure the new mechanism works.
- Removes a setting, because it's not used anymore.
(cherry-pick from eff097448b)
Conflicts:
modules/context/context_cookie.go
trivial context conflicts
routers/web/web.go
ctx.GetSiteCookie(setting.CookieRememberName) moved from services/auth/middleware.go
Backport of #27205Fixes#27174
`release` is a reserved keyword in MySql. I can't reproduce the issue on
my setup and we have a test for that code but it seems there can be
setups where it fails.
(cherry picked from commit eae6985b63)
backport #26991
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 .
(cherry picked from commit 9df573bddc)
System users (Ghost, ActionsUser, etc) have a negative id and may be
the author of a comment, either because it was created by a now
deleted user or via an action using a transient token.
The GetPossibleUserByID function has special cases related to system
users and will not fail if given a negative id.
Refs: https://codeberg.org/forgejo/forgejo/issues/1425
(cherry picked from commit 97667e06b3)
Backport #26664 by @CaiCandong
> ### 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: CaiCandong <50507092+CaiCandong@users.noreply.github.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
(cherry picked from commit 93c36f395c)
- Backport of https://codeberg.org/forgejo/forgejo/pulls/1284
- Databases are one of the most important parts of Forgejo, every
interaction with Forgejo uses the database in one way or another.
Therefore, it is important to maintain the database and recognize when
Forgejo is not doing well with the database. Forgejo already has the
option to log *every* SQL query along with its execution time, but
monitoring becomes impractical for larger instances and takes up
unnecessary storage in the logs.
- Add a QoL enhancement that allows instance administrators to specify a
threshold value beyond which query execution time is logged as a warning
in the xorm logger. The default value is a conservative five seconds to
avoid this becoming a source of spam in the logs.
- The use case for this patch is that with an instance the size of Codeberg, monitoring SQL logs is not very fruitful and most of them are uninteresting. Recently, in the context of persistent deadlock issues (https://codeberg.org/forgejo/forgejo/issues/220), I have noticed that certain queries hold locks on tables like comment and issue for several seconds. This patch helps to identify which queries these are and when they happen.
- Added unit test.
Backport of #25613Fixes#25564Fixes#23191
- Api v2 search endpoint should return only the latest version matching
the query
- Api v3 search endpoint should return `take` packages not package
versions
(cherry picked from commit 762d4245fb)
Backport #26286 by @wxiaoguang
1. Allow leading and trailing spaces by user input, these spaces have
already been trimmed at backend
2. Allow using dots in the topic
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit fcd055c34a)
Backport #26179 by @CaiCandong
In the original implementation, we can only get the first 30 records of
the commit status (the default paging size), if the commit status is
more than 30, it will lead to the bug #25990. I made the following two
changes.
- On the page, use the ` db.ListOptions{ListAll: true}` parameter
instead of `db.ListOptions{}`
- The `GetLatestCommitStatus` function makes a determination as to
whether or not a pager is being used.
fixed#25990
Co-authored-by: caicandong <50507092+CaiCandong@users.noreply.github.com>
(cherry picked from commit 060026995a)
The API should only return the real Mail of a User, if the caller is
logged in. The check do to this don't work. This PR fixes this. This not
really a security issue, but can lead to Spam.
---------
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit ea385f5d39)
- The action tables can become very large as it's a dumpster for every
action that an user does on an repository.
- The following query: `DELETE FROM action WHERE comment_id IN (SELECT id FROM comment WHERE
issue_id=?)` is not using indexes for `comment_id` and is instead using
an full table scan by MariaDB.
- Rewriting the query to use an JOIN will allow MariaDB to use the
index.
- More information: https://codeberg.org/Codeberg-Infrastructure/techstack-support/issues/9
- Backport https://codeberg.org/forgejo/forgejo/pulls/1154
Backport #26182 by @Zettat123
Fix#25934
Add `ignoreGlobal` parameter to `reqUnitAccess` and only check global
disabled units when `ignoreGlobal` is true. So the org-level projects
and user-level projects won't be affected by global disabled
`repo.projects` unit.
Co-authored-by: Zettat123 <zettat123@gmail.com>
(cherry picked from commit 3a29712e0a)
Backport #26192 by @KN4CK3R
Fixes#25918
The migration fails on MSSQL because xorm tries to update the primary
key column. xorm prevents this if the column is marked as auto
increment:
c622cdaf89/internal/statements/update.go (L38-L40)
I think it would be better if xorm would check for primary key columns
here because updating such columns is bad practice. It looks like if
that auto increment check should do the same.
fyi @lunny
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit ecfbcced46)
Backport #26122 by @Zettat123
This PR
- Fix#26093. Replace `time.Time` with `timeutil.TimeStamp`
- Fix#26135. Add missing `xorm:"extends"` to `CountLFSMetaObject` for
LFS meta object query
- Add a unit test for LFS meta object garbage collection
Co-authored-by: Zettat123 <zettat123@gmail.com>
(cherry picked from commit a12d036a68)
- Follow up for: #540, #802
- Add API routes for user blocking from user and organization
perspective.
- The new routes have integration testing.
- The new model functions have unit tests.
- Actually quite boring to write and to read this pull request.
(cherry picked from commit f3afaf15c7)
(cherry picked from commit 6d754db3e5)
(cherry picked from commit d0fc8bc9d3)
(cherry picked from commit 9a53b0d1a0)
(cherry picked from commit 44a2a4fd48)
(cherry picked from commit 182025db9c)
(cherry picked from commit 558a35963e)
- Resolves#476
- Follow up for: #540
- Ensure that the doer and blocked person cannot follow each other.
- Ensure that the block person cannot watch doer's repositories.
- Add unblock button to the blocked user list.
- Add blocked since information to the blocked user list.
- Add extra testing to moderation code.
- Blocked user will unwatch doer's owned repository upon blocking.
- Add flash messages to let the user know the block/unblock action was successful.
- Add "You haven't blocked any users" message.
- Add organization blocking a user.
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/802
(cherry picked from commit 0505a10421)
(cherry picked from commit 37b4e6ef9b)
(cherry picked from commit 217475385a)
(cherry picked from commit f2c38ce5c2)
(cherry picked from commit 1edfb68137)
(cherry picked from commit 2cbc12dc74)
(cherry picked from commit 79ff020f18)
- Add the ability to block a user via their profile page.
- This will unstar their repositories and visa versa.
- Blocked users cannot create issues or pull requests on your the doer's repositories (mind that this is not the case for organizations).
- Blocked users cannot comment on the doer's opened issues or pull requests.
- Blocked users cannot add reactions to doer's comments.
- Blocked users cannot cause a notification trough mentioning the doer.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/540
(cherry picked from commit 687d852480)
(cherry picked from commit 0c32a4fde5)
(cherry picked from commit 1791130e3c)
(cherry picked from commit 00f411819f)
(cherry picked from commit e0c039b0e8)
(cherry picked from commit b5a058ef00)
(cherry picked from commit 5ff5460d28)
(cherry picked from commit 97bc6e619d)
- Implements https://codeberg.org/forgejo/discussions/issues/32#issuecomment-918737
- Allows to add Forgejo-specific migrations that don't interfere with Gitea's migration logic. Please do note that we cannot liberally add migrations for Gitea tables, as they might do their own migrations in a future version on that table, and that could undo our migrations. Luckily, we don't have a scenario where that's needed and thus not taken into account.
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/795
(cherry picked from commit 8ee32978c0)
(cherry picked from commit c240b34f59)
(cherry picked from commit 03936c6492)
(cherry picked from commit 8bd051e6df)
(cherry picked from commit 2c55a40c79)
(cherry picked from commit 260d938e92)
(cherry picked from commit cf7c08031f)
(cherry picked from commit 59c1547517)
Backport #25806 by @yp05327
sort type `oldest` should be `Asc`.
Added a test for this.
I see we have `SearchOrderBy` in db model, but we are using many
different ways to define the sort type.
~Maybe we can improve this later.~
↑ Improved in this PR
Co-authored-by: yp05327 <576951401@qq.com>
