Always enable caches #28527
Merged
Always enable caches #28527
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wxiaoguang
approved these changes
Dec 19, 2023
delvh
approved these changes
Dec 19, 2023
zjjhot
added a commit
to zjjhot/gitea
that referenced
this pull request
Dec 22, 2023
* giteaofficial/main: Add more ways to try (go-gitea#28581) Convert to url auth to header auth in tests (go-gitea#28484) Fix 500 error of searching commits (go-gitea#28576) improve possible performance bottleneck (go-gitea#28547) Use information from previous blame parts (go-gitea#28572) Make offline mode as default to no connect external avatar service by default (go-gitea#28548) Fix merging artifact chunks error when minio storage basepath is set (go-gitea#28555) feat: bump `dessant/lock-threads` and `actions/setup-go` to use nodejs20 runtime (go-gitea#28565) Update actions document about comparsion as Github Actions (go-gitea#28560) Fix inperformant query on retrifing review from database. (go-gitea#28552) Fix the issue ref rendering for wiki (go-gitea#28556) Add missing head of lfs client batch (go-gitea#28550) [skip ci] Updated translations via Crowdin Remove deadcode under models/issues (go-gitea#28536) Always enable caches (go-gitea#28527) Improve ObjectFormat interface (go-gitea#28496)
fuxiaohei
pushed a commit
to fuxiaohei/gitea
that referenced
this pull request
Jan 17, 2024
Nowadays, cache will be used on almost everywhere of Gitea and it cannot be disabled, otherwise some features will become unaviable. Then I think we can just remove the option for cache enable. That means cache cannot be disabled. But of course, we can still use cache configuration to set how should Gitea use the cache.
silverwind
pushed a commit
to silverwind/gitea
that referenced
this pull request
Feb 20, 2024
Nowadays, cache will be used on almost everywhere of Gitea and it cannot be disabled, otherwise some features will become unaviable. Then I think we can just remove the option for cache enable. That means cache cannot be disabled. But of course, we can still use cache configuration to set how should Gitea use the cache.
6543
pushed a commit
to 6543-forks/gitea
that referenced
this pull request
Feb 26, 2024
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 <[email protected]> (cherry picked from commit aaaece28e4c6a8980cef932e224e84933d7c9262) (cherry picked from commit 639dafabec0a5c1f943b44ca02f72c5ba2fc5e10) (cherry picked from commit d699c12) [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 e7cb8da * Always enable caches (go-gitea#28527) (cherry picked from commit 43ded8e) 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 go-gitea#2040. Signed-off-by: Gergely Nagy <[email protected]> (cherry picked from commit e35d2af2e56f4ecb3a4f6d1109d02c8aa1a6d182) (cherry picked from commit 03989418a70d3445e0edada7fbe5a4151d7836b1) (cherry picked from commit f50e0dfe5e90d6a31c5b59e687580e8b2725c22b) (cherry picked from commit cad9184a3653e6c80de2e006a0d699b816980987) (cherry picked from commit e2da5d7fe13a685606913a131687a94f9f5fcfeb) (cherry picked from commit 3a80534d4db523efe56b368489f81dc1cb2c99f7)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Nowadays, cache will be used on almost everywhere of Gitea and it cannot be disabled, otherwise some features will become unaviable.
Then I think we can just remove the option for cache enable. That means cache cannot be disabled.
But of course, we can still use cache configuration to set how should Gitea use the cache.
The settings
[cache].ENABLEDand[cache.last_commit].ENABLEDare no longer used and can be safely removed from your config.