When marking notifications read the results may be returned out of order
or be delayed. This PR sends a sequence number to gitea so that the
browser can ensure that only the results of the latest notification
change are shown.
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Following the merging of #14959 - Gitea is a lot more strict regarding the interpretation of `X-Real-IP` and `X-Forwarded-For` headers.
This PR updates the fail2ban documentation to include hints to set: `REVERSE_PROXY_TRUSTED_PROXIES` and `REVERSE_PROXY_LIMIT` appropriately.
See discussion in #16443
Co-authored-by: zeripath <art27@cantab.net>
Unfortunately #16268 contained a terrible error, whereby there was a double
indirection taken when unmarshalling the source data. This fatally breaks
authentication configuration reading.
Fix#16342
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
The move to render custom/public as within /assets in #15219 missed updating
several documentation pages.
This PR updates this documentation.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* add configuration option to restrict users by default
* default IsRestricted permission only set on sign up
setting this in the model messes with other workflows (e.g. syncing LDAP users) where the IsRestricted permission needs to be explicitly set and not overridden by a config value
* fix formatting
* Apply suggestions from code review
* ensure newly created user is set to restricted
* ensure imports are in the correct order
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Retry rename on lock induced failures
Due to external locking on Windows it is possible for an
os.Rename to fail if the files or directories are being
used elsewhere.
This PR simply suggests retrying the rename again similar
to how we handle the os.Remove problems.
Fix#16427
Signed-off-by: Andrew Thornton <art27@cantab.net>
* resolve CI fail
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Change the release cycle to match actual situations
* Update CONTRIBUTING.md
Co-authored-by: zeripath <art27@cantab.net>
Co-authored-by: Lauris BH <lauris@nix.lv>
* Second attempt at preventing zombies
* Ensure that the pipes are closed in ssh.go
* Ensure that a cancellable context is passed up in cmd/* http requests
* Make cmd.fail return properly so defers are obeyed
* Ensure that something is sent to stdout in case of blocks here
Signed-off-by: Andrew Thornton <art27@cantab.net>
* placate lint
Signed-off-by: Andrew Thornton <art27@cantab.net>
* placate lint 2
Signed-off-by: Andrew Thornton <art27@cantab.net>
* placate lint 3
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fixup
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Apply suggestions from code review
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lauris BH <lauris@nix.lv>
* fix: primary email cannot be activated
* Primary email should be activated together with user account when
'RegisterEmailConfirm' is enabled.
* To fix the existing error state. When 'RegisterEmailConfirm' is enabled, the
admin should have permission to modify the activations status of user email.
And the user should be allowed to send activation to primary email.
* Only judge whether email is primary from email_address table.
* Improve logging and refactor isEmailActive
Co-authored-by: zeripath <art27@cantab.net>
* Add option to provide signed token to verify key ownership
Currently we will only allow a key to be matched to a user if it matches
an activated email address. This PR provides a different mechanism - if
the user provides a signature for automatically generated token (based
on the timestamp, user creation time, user ID, username and primary
email.
* Ensure verified keys can act for all active emails for the user
* Add code to mark keys as verified
* Slight UI adjustments
* Slight UI adjustments 2
* Simplify signature verification slightly
* fix postgres test
* add api routes
* handle swapped primary-keys
* Verify the no-reply address for verified keys
* Only add email addresses that are activated to keys
* Fix committer shortcut properly
* Restructure gpg_keys.go
* Use common Verification Token code
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Add checkbox to delete pull branch after successful merge
* Omit DeleteBranchAfterMerge field in json
* Log a warning instead of error when PR head branch deleted
* Add DefaultDeleteBranchAfterMerge to PullRequestConfig
* Add support for delete_branch_after_merge via API
* Fix for API: the branch should be deleted from the HEAD repo
If head and base repo are the same, reuse the already opened ctx.Repo.GitRepo
* Don't delegate to CleanupBranch, only reuse branch deletion code
CleanupBranch contains too much logic that has already been performed by the Merge
* Reuse gitrepo in MergePullRequest
Co-authored-by: Andrew Thornton <art27@cantab.net>
The current default memory cache implementation is unbounded in size and number of
objects cached. This is hardly ideal.
This PR proposes creating a TwoQueue LRU cache as the underlying cache for Gitea.
The cache is limited by the number of objects stored in the cache (rather than size)
for simplicity. The default number of objects is 50000 - which is perhaps too small
as most of our objects cached are going to be much less than 1kB.
It may be worth considering using a different LRU implementation that actively limits
sizes or avoids GC - however, this is just a beginning implementation.
Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath