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 aaaece28e4c6a8980cef932e224e84933d7c9262)
(cherry picked from commit 639dafabec0a5c1f943b44ca02f72c5ba2fc5e10)
(cherry picked from commit d699c12cebea7dbbda950ae257a46d53c39f22ea)
[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 43ded8ee30ab5c7a40a456600cdaa8a0fbdccec2)
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 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)
On activating local accounts, the error message didn't differentiate
between using a wrong or expired token, or a wrong password. The result
could already be obtained from the behaviour (different screens were
presented), but the error message was misleading and lead to confusion
for new users on Codeberg with Forgejo.
Now, entering a wrong password for a valid token prints a different
error message.
The problem was introduced in 0f14f69e60.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Refactor `i18n` to `locale`
- Currently we're using the `i18n` variable naming for the `locale`
struct. This contains locale's specific information and cannot be used
for general i18n purpose, therefore refactoring it to `locale` makes
more sense.
- Ref: https://github.com/go-gitea/gitea/pull/20096#discussion_r906699200
* Update routers/install/install.go
* make blue really blue
* replace blue button and label classes with primary
* add --color-blue-dark
* add light color variants, tweak a few colors
* fix colors
* add comment
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
If the mailer is configured then even if Manual confirm is set an activation email
is still being sent because `handleUserCreated` is not checking for this case.
Fix #17263
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
* Add class to page content to unify top margin
Previously pages would individually set this margin but some didn't so
content would stick to the header without any space. Resolve this by
adding a new class that is added on all pages. The only place where we
remove this margin again is on the pages with menu or wrapper in the
header.
* fix admin notices
* fix team pages
* fix loading segment on gitgraph for arc-green
* fix last missing case
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
* Escape more things that are passed through str2html
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Bloody editors!
Co-authored-by: mrsdizzie <info@mrsdizzie.com>
* Update routers/user/oauth.go
Co-authored-by: mrsdizzie <info@mrsdizzie.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
The choice regarding which forms should or should not trigger a warning
is subjective. I tried to be consistent and not warn about forms that:
- run an action, rather than edit data: search, send an email.
- delete data: a warning about losing data would be confusing
Note that forms on sign-in pages were already ignored (using a selector,
rather than an explicit class on the form element).
Fixes #3698.
This commit improves templates readability, since all of them use consistent
indent with all template command blocks indented too.
1. Indents both HTML containers such as <div>, <p> and Go HTML template blocks
such as {{if}} {{with}}
2. Cleans all trailing white-space
3. Adds trailing last line-break to each file
