Internal nickname format checking is ignored when remote clashing nicknames are handled
Environment
- Installation type (OTP or From Source): Source
- Pleroma version (could be found in the "Version" tab of settings in Pleroma-FE): 2.6.0-fluffytail and current develop commit f74f5e0a
- Elixir version (
elixir -v
for from source installations, N/A for OTP): 1.16.0 - Operating system: Arch Linux
- PostgreSQL version (
psql -V
): 16.1
Bug description
When Pleroma backend encounters a remote clashing nickname with a different ap_id in function maybe_handle_clashing_nickname
, it adds a dot to the nickname and renames it. This misses internal nickname format checking enforced by the local_nickname_regex
and Pleroma doesn't expect this. The local_nickname_regex
is only used for local users, but some parts of the backend probably rely on this behavior even for remote users thus creating this bug.
If I try to create a username with a dot inside it, as is done by Pleroma in the above function maybe_handle_clashing_nickname
, it will fail with an Ecto.changeset error (in validate_format
in ecto to be precise) as shown here. Adding a dot to the above regex is enough for Pleroma to create the account and the account mostly works (see my screenshots in the related thread).
As a result from this behavior, that user cannot be tagged in any posts and the handle isn't properly displayed in the frontend.
Summary
- clashing nicknames with different ap_id miss internal nickname checking
- the affected user cannot be tagged in any posts
- handles are improperly displayed in the frontend
Related thread with screenshots: https://fluffytail.org/notice/AdTquInU8oJeZ9Qp9c