There are a number of tests which require creating a repository on the
fly, and they each do it their own way. To reduce code duplication, lift
out this common pattern into a helper called `CreateDeclarativeRepo()`,
which lets us create a repository, set up enabled and disabled repo
units, and even add, delete, or update files.
Also convert a number of users of this pattern to the new helper - those
users that I introduced, and are in code introduced by Forgejo in the
first place.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 342b7bae3c)
(cherry picked from commit 2ece8764e9)
handleSchedules() is called every time an event is received and will
check the content of the main branch to (re)create scheduled events.
There is no reason why intput.Event will be relevant when the schedule
workflow runs.
(cherry picked from commit 9a712bb276)
(cherry picked from commit 41af36da81)
(cherry picked from commit bb83604fa2)
(cherry picked from commit 65e4503a7a)
(cherry picked from commit e562b6f7a0)
(cherry picked from commit aca2ae2390)
(cherry picked from commit bf2b5ea507)
This function is now being used elsewhere and cannot be reverted. Only
the part that was modified in addition to being moved is deleted.
(cherry picked from commit 72954836a4)
(cherry picked from commit 86f4d1871e)
(cherry picked from commit 8089076ee2)
When displaying the recently pushed branches banner, don't display
branches that have no common history with the default branch. These
branches are usually not meant to be merged, so the banner is just noise
in this case.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2196
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e1fba517f4)
(cherry picked from commit 2d3c81d4f2)
(cherry picked from commit 624a61b3b8)
- When there's a succesful POST operation, it should return a 201 status
code (which is the status code for succesful created) and additionally
the created object.
- Currently for the `POST /repos/{owner}/{repo}/tags` endpoint an 200
status code was documented in the OpenAPI specification, while an 201
status code was actually being returned. In this case the code is
correct and the documented status code needs to be adjusted.
- Resolves#2200
(cherry picked from commit a2939116f5)
(cherry picked from commit 22cff41585)
(cherry picked from commit b23a7f27bb)
When comparing branches, only offer those branches to use as a base
where the repository allows pull requests. Those that do not allow pull
request would result in a 404, so offering them as an option would be
misleading.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2194
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 022d0e0d71)
(cherry picked from commit 957990b36a)
(cherry picked from commit 6d2df72825)
With this change, the "You pushed on branch xyz" banner will be
displayed when either the viewed repository or its base repo (if the
current one's a fork) has pull requests enabled. Previously it only
displayed if the viewed repo had PRs enabled.
Furthermore, if the viewed repository is an original repository that the
viewing user has a fork of, if the forked repository has recently pushed
branches, then the banner will appear for the original repository too.
In this case, the notification will include branches from the viewing
user's fork, and branches they pushed to the base repo, too.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2195
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit a29f10661d)
(cherry picked from commit 70c5e2021d)
(cherry picked from commit 48b25be67a)
- The name could be conflucted with the `GET
/user/applications/oauth2/{id}` operation, as it only differed in a
single letter being uppercase. Change it to be
userGetOAuth2Application**s**, as that's also more accurate for this function.
- Resolves#2163
(cherry picked from commit 1891dac547)
(cherry picked from commit 68fceb9b7a)
(cherry picked from commit 7335d6de54)
- Document the correct content types for Git archives. Add code that
actually sets the correct application type for `.zip` and `.tar.gz`.
- When an action (POST/PUT/DELETE method) was successful, an 204 status
code should be returned instead of status code 200.
- Add and adjust integration testing.
- Resolves#2180
- Resolves#2181
(cherry picked from commit 6c8c4512b5)
(cherry picked from commit 3f74bcb14d)
(cherry picked from commit 6ed9057fd7)
Recognise the `linguist-documentation` and `linguist-detectable`
attributes in `.gitattributes` files, and use them in
`GetLanguageStats()` to make a decision whether to include a particular
file in the stats or not.
This allows one more control over which files in their repositories
contribute toward the language statistics, so that for a project that is
mostly documentation, the language stats can reflect that.
Fixes#1672.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 6d4e02fe5f)
(cherry picked from commit ee1ead8189)
(cherry picked from commit 2dbec730e8)
Instead of repeating the tests that verify the ID of a comment
is related to the repository of the API endpoint, add the middleware
function commentAssignment() to assign ctx.Comment if the ID of the
comment is verified to be related to the repository.
There already are integration tests for cases of potential unrelated
comment IDs that cover some of the modified endpoints which covers the
commentAssignment() function logic.
* TestAPICommentReactions - GetIssueCommentReactions
* TestAPICommentReactions - PostIssueCommentReaction
* TestAPICommentReactions - DeleteIssueCommentReaction
* TestAPIEditComment - EditIssueComment
* TestAPIDeleteComment - DeleteIssueComment
* TestAPIGetCommentAttachment - GetIssueCommentAttachment
The other modified endpoints do not have tests to verify cases of
potential unrelated comment IDs. They no longer need to because they
no longer implement the logic to enforce this. They however all have
integration tests that verify the commentAssignment() they now rely on
does not introduce a regression.
* TestAPIGetComment - GetIssueComment
* TestAPIListCommentAttachments - ListIssueCommentAttachments
* TestAPICreateCommentAttachment - CreateIssueCommentAttachment
* TestAPIEditCommentAttachment - EditIssueCommentAttachment
* TestAPIDeleteCommentAttachment - DeleteIssueCommentAttachment
(cherry picked from commit d414376d74)
(cherry picked from commit 09db07aeae)
(cherry picked from commit f44830c3cb)
Conflicts:
modules/context/api.go
https://codeberg.org/forgejo/forgejo/pulls/2249
(cherry picked from commit 9d1bf7be15)
- Unset the http proxies environments for the `TestWebhookProxy`.
- Resolves#2132
(cherry picked from commit 244b9786fc)
(cherry picked from commit 8602dfa6a2)
(cherry picked from commit 8621449209)
(cherry picked from commit aefa77f917)
The message telling us that we recently pushed on a branch should
include a link to said branch, not just a "New pull request" button.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d9662d03a4)
(cherry picked from commit 2527e09125)
(cherry picked from commit 0ddefdf9f4)
(cherry picked from commit e9ff354f7c)
When searching for repository topics, either via the API, or via
Explore, paging did not work correctly, because it only applied when the
`page` parameter was non-zero. Paging should have applied when the page
size is greater than zero, which is what this patch does.
As a result, both the API, and the Explore endpoint will return paged
results (30 by default). As such, when managing topics on the frontend,
the offered completions will also be limited to a pageful of results,
based on what the user has already typed.
This drastically reduces the amount of traffic, and also the number of
the topics to choose from, and thus, the rendering time too.
The topics will be returned by popularity, with most used topics first.
A single page will contain `[api].DEFAULT_PAGING_NUM` (30 by default)
items that match the query. That's plenty to choose from.
Fixes#132.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 64d4ff41db)
(cherry picked from commit 06b808fa2c)
(cherry picked from commit 9205c9266a)
(cherry picked from commit 47863d4f72)
- When the database returns an error about the SQL query, the error is
logged but not the SQL query and arguments, which is just as valuable as
the vague deeply hidden documented error that the database returns.
It's possible to log the SQL query by logging **all** SQL queries. For
bigger instances such as Codeberg, this is not a viable option.
- Adds a new hook, enabled by default, to log SQL queries with their
arguments and the error returned by the database when the database
returns an error.
- This likely needs some fine tuning in the future to decide when to
enable this, as the error is already logged and if people have the
`[database].LOG_SQL` option enabled, the SQL would be logged twice. But
given that it's an rare occurence for SQL queries to error, it's fine to
leave that as-is.
- Ref: https://codeberg.org/forgejo/forgejo/issues/1998
(cherry picked from commit 866229bc32)
(cherry picked from commit 96dd3e87cf)
(cherry picked from commit e165510317)
(cherry picked from commit 1638e2b3f5)
services: in loadOneBranch, return if CountDivergingCommits fail
If we can't count the number of diverging commits for one reason or
another (such as the branch being in the database, but missing from
disk), rather than logging an error and continuing into a crash (because
`divergence` will be nil), return an error instead.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 8266105f24)
services: Gracefully handle missing branches
When loading branches, if loading one fails, log an error, and ignore
the branch, rather than returning and causing an internal server error.
Ideally, we would only ignore the error if it was caused by a missing
branch, and do it silently, like the respective API endpoint does.
However, veryfing that at this place is not very practical, so for the
time being, ignore any and all branch loading errors.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e552a8fd62)
tests: Add a testcase for missing branches
This tests the scenario reported in Codeberg/Community#1408: a branch
that is recorded in the database, but missing on disk was causing
internal server errors. With recent changes, that is no longer the case,
the error is logged and then ignored.
This test case tests this behaviour, that the repo's branches page on
the web UI functions even if the git branch is missing.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e20eb7b385)
tests: More testing in TestDatabaseMissingABranch
In the `TestDatabaseMissingABranch` testcase, make sure that the
branches are in sync between the db and git before deleting a branch via
git, then compare the branch count from the web UI, making sure that it
returns an out-of-sync value first, and the correct one after another
sync.
This is currently tested by scraping the UI, and relies on the fact that
the branch counter is out of date before syncing. If that issue gets
resolved, we'll have to adjust the test to verify the sync another way.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 8c2ccfcece)
(cherry picked from commit 439fadf563)
(cherry picked from commit 44dd80552c)
(cherry picked from commit 37b91fe6f2)
- It's possible that `canSoftDeleteContentHistory` is called without
`ctx.Doer` being set, such as an anonymous user requesting the
`/content-history/detail` endpoint.
- Add a simple condition to always set to `canSoftDelete` to false if an
anonymous user is requesting this, this avoids a panic in the code that
assumes `ctx.Doer` is set.
- Added integration testing.
(cherry picked from commit 0b5db0dcc6)
(cherry picked from commit 30d168bcc8)
(cherry picked from commit 19be82b7ef)
(cherry picked from commit 334b703b17)
Refs: https://codeberg.org/forgejo/forgejo/issues/2109
(cherry picked from commit 8b4ba3dce7)
(cherry picked from commit 196edea0f9)
[GITEA] POST /repos/{owner}/{repo}/pulls/{index}/reviews/{id}/comments (squash) do not implicitly create a review
If a comment already exists in a review, the comment is added. If it
is the first comment added to a review, it will implicitly create a
new review instead of adding to the existing one.
The pull_service.CreateCodeComment function is responsibe for this
behavior and it will defer to createCodeComment once the review is
determined, either because it was found or because it was created.
Rename createCodeComment into CreateCodeCommentKnownReviewID to expose
it and change the API endpoint to use it instead. Since the review is
provided by the user and verified to exist already, there is no need
for the logic implemented by CreateCodeComment.
The tests are modified to remove the initial comment from the fixture
because it was creating the false positive. I was verified to fail
without this fix.
(cherry picked from commit 6a555996dc)
(cherry picked from commit b173a0ccee)
(cherry picked from commit 838ab9740a)
- Remove `container` to remove unnecessary margins being added to the
whole page.
- Specify max width for the 404 image to avoid overflow of the image.
(cherry picked from commit b1ced72ce5)
(cherry picked from commit ef5e1b01b8)
(cherry picked from commit c321af3d5f)
(cherry picked from commit d6e99436b5)
Expose the repository flags feature over the API, so the flags can be
managed by a site administrator without using the web API.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit bac9f0225d)
(cherry picked from commit e7f5c1ba14)
(cherry picked from commit 95d9fe19cf)
(cherry picked from commit 7fc51991e4)
This implements "repository flags", a way for instance administrators to
assign custom flags to repositories. The idea is that custom templates
can look at these flags, and display banners based on them, Forgejo does
not provide anything built on top of it, just the foundation. The
feature is optional, and disabled by default. To enable it, set
`[repository].ENABLE_FLAGS = true`.
On the UI side, instance administrators will see a new "Manage flags"
tab on repositories, and a list of enabled tags (if any) on the
repository home page. The "Manage flags" page allows them to remove
existing flags, or add any new ones that are listed in
`[repository].SETTABLE_FLAGS`.
The model does not enforce that only the `SETTABLE_FLAGS` are present.
If the setting is changed, old flags may remain present in the database,
and anything that uses them, will still work. The repository flag
management page will allow an instance administrator to remove them, but
not set them, once removed.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit ba735ce222)
(cherry picked from commit f09f6e029b)
(cherry picked from commit 2f8b041489)
(cherry picked from commit d3186ee5f4)
Files can have an RSS feed, but those only make sense when taken in the
context of a branch. There is no history to make a feed of on a tag or a
commit: they're static. Forgejo does not provide a feed for them for
this reason.
However, the file view on the web UI was offering a link to these
non-existent feeds. With this patch, it does that no longer, and only
provides a link when viewing the file in the context of a branch.
Fixes#2102.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b48d21ea7)
(cherry picked from commit 70cb266760)
(cherry picked from commit 69b45c3fea)
Conflicts:
options/locale/locale_en-US.ini
https://codeberg.org/forgejo/forgejo/pulls/2249
(cherry picked from commit 639a2c0741)
When trying to find a `README.md` in a `.profile` repo, do so case
insensitively. This change does not make it possible to render readmes
in formats other than Markdown, it just removes the hard-coded
"README.md".
Also adds a few tests to make sure the change works.
Fixes#1494.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit edd219d8e9)
(cherry picked from commit 2c0105ef17)
(cherry picked from commit 3975a9f3aa)
(cherry picked from commit dee4a18423)
(cherry picked from commit 60aee6370f)
- 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)
(cherry picked from commit 8c737a802b)
(cherry picked from commit 6b7c7d18dc)
(cherry picked from commit a2be4fab27)
(cherry picked from commit a1125268ac)
Adds a new `/{username}/{repo}/badges` family of routes, which redirect
to various shields.io badges. The goal is to not reimplement badge
generation, and delegate it to shields.io (or a similar service), which
are already used by many. This way, we get all the goodies that come
with it: different styles, colors, logos, you name it.
So these routes are just thin wrappers around shields.io that make it
easier to display the information we want. The URL is configurable via
`app.ini`, and is templatable, allowing to use alternative badge
generator services with slightly different URL patterns.
Additionally, for compatibility with GitHub, there's an
`/{username}/{repo}/actions/workflows/{workflow_file}/badge.svg` route
that works much the same way as on GitHub. Change the hostname in the
URL, and done.
Fixes gitea#5633, gitea#23688, and also fixes#126.
Work sponsored by Codeberg e.V.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit fcd0f61212)
(cherry picked from commit 20d14f7844)
(cherry picked from commit 4359741431)
(cherry picked from commit 35cff45eb8)
(cherry picked from commit 2fc0d0b8a3)
When displaying the repo home view, do not redirect to unit types that
can't be defaults (which, at the moment, are the external wiki and issue
tracker unit types).
If we'd redirect to those, that would mean that a repository with the
Code unit disabled, and an external issue tracker would immediately
redirect to the external issue tracker, making it harder to reach other,
non-external units of the repo.
Fixes#1965.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 44078e5460)
(cherry picked from commit 1868dec2e4)
(cherry picked from commit c3a8e98870)
(cherry picked from commit 9266b1916f)
(cherry picked from commit 8fa5ff65af)
- The transaction in combination with Git push was causing deadlocks if
you had the `push_update` queue set to `immediate`. This was the root
cause of slow integration tests in CI.
- Remove the sync branch code as this is already being done in the Git
post-receive hook.
- Add tests to proof the branch models are in sync even with this code
removed.
(cherry picked from commit 90110e1f44)
(cherry picked from commit a064065cb9)
(cherry picked from commit 7713e558eb)
Conflicts:
services/repository/branch.go
https://codeberg.org/forgejo/forgejo/pulls/2068
(cherry picked from commit 3bb73e0813)
(cherry picked from commit c557540926)
(cherry picked from commit 986be6171a)
(cherry picked from commit 7a343877f1)
(cherry picked from commit 51425500f2)
Adds `[repository].DOWNLOAD_OR_CLONE_METHODS` (defaulting to
"download-zip,download-targz,download-bundle,vscode-clone"), which lets
an instance administrator override the additional clone methods
displayed on the repository home view.
This is purely display-only, the clone methods not listed here are still
available, unless disabled elsewhere. They're just not displayed.
Fixes#710.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 2aadcf4946)
(cherry picked from commit 42ac34fbf9)
(cherry picked from commit bd231b0245)
(cherry picked from commit 3d3366dbbe)
(cherry picked from commit 0157fb9b88)
(cherry picked from commit bee88f6a83)
- Add condition to ensure doer isn't nil when using it.
- Added unit test.
- Resolves#2055
(cherry picked from commit 8f1a74fb29)
(cherry picked from commit 60ac881776)
(cherry picked from commit 5fdc461ac5)
(cherry picked from commit 70623e8da1)
(cherry picked from commit 1d5153aaf6)
(cherry picked from commit 3927f0c8b2)
- Rewrite `UpdateCommentsMigrationsByType` to not use `WHERE IN` as
that's a performance diaster for MariaDB, it now use batching to query
the the relevant comment IDs via JOINs (which is not possible in a
UPDATE query for SQLite) and then update them in a seperate query.
- Add unit test.
- Resolves https://codeberg.org/forgejo/forgejo/issues/1856
(cherry picked from commit 8098ca9d2e)
Conflicts:
models/issues/comment.go
https://codeberg.org/forgejo/forgejo/pulls/2075
(cherry picked from commit ca65deba1c)
(cherry picked from commit 0e1e09e77d)
(cherry picked from commit 19013ba5ea)
(cherry picked from commit 23c887f97e)
(cherry picked from commit b3321d1a84)
- The endpoint was moved from being an API endpoint to an web endpoint
with JSON result. However the API context isn't the same as the web
context, for example the `ctx.Error` only takes in the first two
arguments into consideration and doesn't do logging, which is not the
same behavior as the API context where there's three arguments and does
do logging and only reveal the function + error if the user is admin.
- Remove any details in the error message and do the logging seperatly,
this is somewhat consistent with how other API endpoints behave.
- Ref: https://codeberg.org/forgejo/forgejo/issues/1998
(cherry picked from commit fe71e32ace)
(cherry picked from commit c89e0735fa)
(cherry picked from commit 4c04dcfc59)
(cherry picked from commit 66eae1041c)
(cherry picked from commit 7b70fa9392)
(cherry picked from commit abf64ca0e3)
This is largely based on gitea#6312 by @ashimokawa, with updates and
fixes by myself, and incorporates the review feedback given in that pull
request, and more.
What this patch does is add a new "default_permissions" column to the
`repo_units` table (defaulting to read permission), adjusts the
permission checking code to take this into consideration, and then
exposes a setting that lets a repo administrator enable any user on a
Forgejo instance to edit the repo's wiki (effectively giving the wiki
unit of the repo "write" permissions by default).
By default, wikis will remain restricted to collaborators, but with the
new setting exposed, they can be turned into globally editable wikis.
FixesCodeberg/Community#28.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 4b74439922)
(cherry picked from commit 337cf62c10)
(cherry picked from commit b6786fdb32)
(cherry picked from commit a5d2829a10)
[GITEA] Optionally allow anyone to edit Wikis (squash) AddTokenAuth
(cherry picked from commit fed50cf72e)
(cherry picked from commit 42c55e494e)
(cherry picked from commit e3463bda47)
- If the session doesn't exist, it shouldn't be expected that the
variable is non-nil. Define the session variable instead and insert that.
- Add unit tests to test the behavior of the database sessions code .
- Regression caused by dd30d9d5c0.
- Resolves https://codeberg.org/forgejo/forgejo/issues/2042
(cherry picked from commit 90307ad200)
(cherry picked from commit 874ef1978d)
(cherry picked from commit 27d5f035fc)
(cherry picked from commit 65dbc4303b)
[GITEA] Fix session generation for database (squash) timeutil.Mock
because of e743570f65 * Refactor timeutil package (#28623)
(cherry picked from commit acc6b51be2)
(cherry picked from commit 02b74317f2)
(cherry picked from commit 63b9b624bd)
(cherry picked from commit 7752ff8baa)
(cherry picked from commit c0af4d9438)
do not reuse the payload of the event that triggered the creation of
the scheduled event. Create a new one instead that contains no other
information than the event name in the action field ("schedule").
(cherry picked from commit 0b40ca1ea5)
(cherry picked from commit f86487432b)
(cherry picked from commit 4bd5d2e9d0)
(cherry picked from commit d10830e238)
(cherry picked from commit 53f5a3aa91)
(cherry picked from commit 9ed1487b73)
(cherry picked from commit 6a39978851)
- When the user is not found in `reloadparam`, early return when the
user is not found to avoid calling `IsUserVisibleToViewer` which in turn
avoids causing a NPE.
- This fixes the case that a 500 error and 404 error is shown on the
same page.
- Add integration test for non-existant user RSS.
- Regression by c6366089df
(cherry picked from commit f0e0696278)
(cherry picked from commit 75d8066908)
(cherry picked from commit 4d0a1e0637)
(cherry picked from commit 5f40a485da)
(cherry picked from commit c4cb7812e3)
(cherry picked from commit d31ce2f03d)
(cherry picked from commit cfebef4f82)
- This adds coverage to the most common and the edge cases of what the
footnote implementation should be capable of. This was partly done to
ensure no hidden surprises when changing the implementation, as markdown
rendering is one of the more important features of Forgejo.
(cherry picked from commit 16ecdb4170)
(cherry picked from commit 19dc5ef5e5)
(cherry picked from commit d5955efc0a)
(cherry picked from commit 2cdaf10836)
(cherry picked from commit 251b567794)
Conflicts:
modules/markup/markdown/markdown_test.go
https://codeberg.org/forgejo/forgejo/pulls/2153
(cherry picked from commit f863f4b005)
(cherry picked from commit f39f108934)
(cherry picked from commit 6d46f9ee40)
During registration, one may be required to give their email address, to
be verified and activated later. However, if one makes a mistake, a
typo, they may end up with an account that cannot be activated due to
having a wrong email address.
They can still log in, but not change the email address, thus, no way to
activate it without help from an administrator.
To remedy this issue, lets allow changing the email address for logged
in, but not activated users.
This fixes gitea#17785.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit aaaece28e4)
(cherry picked from commit 639dafabec)
(cherry picked from commit d699c12ceb)
[GITEA] Allow changing the email address before activation (squash) cache is always active
This needs to be revisited because the MailResendLimit is not enforced
and turns out to not be tested.
See e7cb8da2a8 * Always enable caches (#28527)
(cherry picked from commit 43ded8ee30)
Rate limit pre-activation email change separately
Changing the email address before any email address is activated should
be subject to a different rate limit than the normal activation email
resending. If there's only one rate limit for both, then if a newly
signed up quickly discovers they gave a wrong email address, they'd have
to wait three minutes to change it.
With the two separate limits, they don't - but they'll have to wait
three minutes before they can change the email address again.
The downside of this setup is that a malicious actor can alternate
between resending and changing the email address (to something like
`user+$idx@domain`, delivered to the same inbox) to effectively halving
the rate limit. I do not think there's a better solution, and this feels
like such a small attack surface that I'd deem it acceptable.
The way the code works after this change is that `ActivatePost` will now
check the `MailChangeLimit_user` key rather than `MailResendLimit_user`,
and if we're within the limit, it will set `MailChangedJustNow_user`. The
`Activate` method - which sends the activation email, whether it is a
normal resend, or one following an email change - will check
`MailChangedJustNow_user`, and if it is set, it will check the rate
limit against `MailChangedLimit_user`, otherwise against
`MailResendLimit_user`, and then will delete the
`MailChangedJustNow_user` key from the cache.
Fixes#2040.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e35d2af2e5)
(cherry picked from commit 03989418a7)
(cherry picked from commit f50e0dfe5e)
(cherry picked from commit cad9184a36)
(cherry picked from commit e2da5d7fe1)
(cherry picked from commit 3a80534d4d)
It will determine how anchors are created and will break existing
links otherwise.
Adapted from Revert "Make `user-content-* ` consistent with github (#26388)
(cherry picked from commit 1666fba8f5)
(cherry picked from commit 48f38280e8)
(cherry picked from commit 03adb3a2b4)
(cherry picked from commit a0ad36f0ad)
(cherry picked from commit 3aac990064)
(cherry picked from commit 137daabc9b)
(cherry picked from commit b438aed4c1)
(cherry picked from commit 90b36f2e67)
Similar to how some other parts of the web UI support a `/latest` path
to directly go to the latest of a certain thing, let the Actions web UI
do the same: `/{owner}/{repo}/actions/runs/latest` will redirect to the
latest run, if there's one available.
Fixes gitea#27991.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit f67ccef1dd)
Code cleanup in the actions.ViewLatest route handler
Based on feedback received after the feature was merged, use
`ctx.NotFound` and `ctx.ServerError`, and drop the use of the
unnecessary `ctx.Written()`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 74e42da563)
(cherry picked from commit f7535a1cef)
(cherry picked from commit 1a90cd37c3)
(cherry picked from commit d86d71340a)
(cherry picked from commit 9e5cce1afc)
(cherry picked from commit 2013fb3fab)
(cherry picked from commit 88b9d21d11)
(cherry picked from commit 72c020298e)
(cherry picked from commit 6525f730df)
