Forgejo sets a label and will notify this when opening the pull
request. Triggering when it opens will make two workflows for the same
SHA. Re-opening is a border case that is not needed.
- Currently if the password, primary mail, TOTP or security keys are
changed, no notification is made of that and makes compromising an
account a bit easier as it's essentially undetectable until the original
person tries to log in. Although other changes should be made as
well (re-authing before allowing a password change), this should go a
long way of improving the account security in Forgejo.
- Adds a mail notification for password and primary mail changes. For
the primary mail change, a mail notification is sent to the old primary
mail.
- Add a mail notification when TOTP or a security keys is removed, if no
other 2FA method is configured the mail will also contain that 2FA is
no longer needed to log into their account.
- `MakeEmailAddressPrimary` is refactored to the user service package,
as it now involves calling the mailer service.
- Unit tests added.
- Integration tests added.
- Existing gear icon keyup handler fixed:
moved the handler onto its descendant button,
to prevent it from incorrectly firing on the check-box elements
- Check-box elements: keyup elements for space and enter added,
as well as tabindex elements to make them able to gain focus
<!--
Before submitting a PR, please read the contributing guidelines:
https://codeberg.org/forgejo/forgejo/src/branch/forgejo/CONTRIBUTING.md
-->
To test the check boxes:
- Set up an action, and visit the action's job page
- Navigate onto the job container (via Tab et al.)
- Use the gear icon with Space or Enter
- Tick the check-box items with Space or Enter
To test the elements beside the chevron icons:
- Navigate onto the element via Tab et al.
- Open/close them via Space or Enter
I have not had a chance to test the latter fix (https://codeberg.org/forgejo/forgejo/issues/4476#issuecomment-2092312) myself yet; feel free to reject this one in case the latter fix does not work as it should, and I will break this up into two separate pull requests.
<!--start release-notes-assistant-->
## Draft release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- User Interface bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/4490)</a>: <!--number 4490 --><!--line 0 --><!--description W2FjY2Vzc2liaWxpdHldIEFkZCBrZXlib2FyZCBzdXBwb3J0IGZvciB0ZXN0IGFjdGlvbnM=-->[accessibility] Add keyboard support for test actions<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4490
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: banaanihillo <banaanihillo@noreply.codeberg.org>
Co-committed-by: banaanihillo <banaanihillo@noreply.codeberg.org>
* if <!-- is inserted just after a <!-- --> it will not render
well, it needs to be separated by a newline
* do not use ? in sed -E, it is not the same as with JavaScript
GITHUB_TOKEN does not have permission to write the repository and is
not allowed to edit or comment on pull requests because of that. A PAT
from a regular user who does **not** have permission to write to the
repository either but who is in a the contributors team will have
permissions to do that because there is a "write pull request"
permission given to the team.
If the 'worth a release-note' label is set, add a release note entry
to the description of the pull request as a preview.
* use the `release-notes/<pr-number>.md` file if any
* otherwise use the pull request title
Refs: https://code.forgejo.org/forgejo/release-notes-assistant
- It's possible to detect if refresh tokens are used more than once, if
it's used more than it's a indication of a replay attack and it should
invalidate the associated access token. This behavior is controlled by
the `INVALIDATE_REFRESH_TOKENS` setting.
- Altough in a normal scenario where TLS is being used, it should be
very hard to get to situation where replay attacks are being used, but
this is better safe than sorry.
- Enable `INVALIDATE_REFRESH_TOKENS` by default.
- Add https://github.com/playwright-community/eslint-plugin-playwright
as a linter for the playwright tests.
- `no-networkidle` and `no-conditional-in-test` are disabled as fixing
those doesn't seem to really improve testing quality for our use case.
- Some non-recommended linters are enabled to ensure consistency (the
prefer rules).
* Closes https://codeberg.org/forgejo/forgejo/issues/4563
* A followup to my 2024-February investigation in the Localization room
* Restore Malayalam and Serbian locales that were deleted in 067b0c2664 and f91092453e. Bulgarian was also deleted, but we already have better Bulgarian translation.
* Remove ml-IN from the language selector. It was not usable for 1.5 years, has ~18% completion and was not maintained in those ~1.5 years. It could also have placeholder bugs due to refactors.
Restoring files gives the translators a base to work with and makes the project advertised on Weblate homepage for logged in users in the Suggestions tab. Unlike Gitea, we store our current translations directly in the repo and not on a separate platform, so it makes sense to add these files back.
Removing selector entry avoids bugs and user confusion. I will make a followup for the documentation.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4576
Reviewed-by: twenty-panda <twenty-panda@noreply.codeberg.org>
This adds a release note file for features cherry picked during the
2024-30 weekly gitea->forgejo cherry pick.
Thanks @earl-warren for the notes themselves!
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This leverages the existing `sync_external_users` cron job to
synchronize the `IsActive` flag on users who use an OAuth2 provider set
to synchronize. This synchronization is done by checking for expired
access tokens, and using the stored refresh token to request a new
access token. If the response back from the OAuth2 provider is the
`invalid_grant` error code, the user is marked as inactive. However, the
user is able to reactivate their account by logging in the web browser
through their OAuth2 flow.
Also changed to support this is that a linked `ExternalLoginUser` is
always created upon a login or signup via OAuth2.
Ideally, we would also refresh permissions from the configured OAuth
provider (e.g., admin, restricted and group mappings) to match the
implementation of LDAP. However, the OAuth library used for this `goth`,
doesn't seem to support issuing a session via refresh tokens. The
interface provides a [`RefreshToken`
method](https://github.com/markbates/goth/blob/master/provider.go#L20),
but the returned `oauth.Token` doesn't implement the `goth.Session` we
would need to call `FetchUser`. Due to specific implementations, we
would need to build a compatibility function for every provider, since
they cast to concrete types (e.g.
[Azure](https://github.com/markbates/goth/blob/master/providers/azureadv2/azureadv2.go#L132))
---------
Co-authored-by: Kyle D <kdumontnu@gmail.com>
(cherry picked from commit 416c36f3034e228a27258b5a8a15eec4e5e426ba)
Conflicts:
- tests/integration/auth_ldap_test.go
Trivial conflict resolved by manually applying the change.
- routers/web/auth/oauth.go
Technically not a conflict, but the original PR removed the
modules/util import, which in our version, is still in use. Added it
back.
Make it posible to let mails show e.g.:
`Max Musternam (via gitea.kithara.com) <gitea@kithara.com>`
Docs: https://gitea.com/gitea/docs/pulls/23
---
*Sponsored by Kithara Software GmbH*
(cherry picked from commit 0f533241829d0d48aa16a91e7dc0614fe50bc317)
Conflicts:
- services/mailer/mail_release.go
services/mailer/mail_test.go
In both cases, applied the changes manually.
