Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible to create domain blocks when a stricter limit already exists in Admin UI #29127

Closed
ThisIsMissEm opened this issue Feb 7, 2024 · 4 comments · Fixed by #30119
Closed
Labels
bug Something isn't working status/to triage This issue needs to be triaged

Comments

@ThisIsMissEm
Copy link
Contributor

Steps to reproduce the problem

  1. Go to /admin/instances?limited=1 to manage federation
  2. Add a domain block for example (noop/none severity)
  3. Using the API try to create a domain block for test.example observe that an error is returned
  4. Go back to the admin UI and create a domain block for test.example observe that no error is returned and the block is successfully created.

Expected behaviour

Both methods for creating domain blocks should have same behaviour

Actual behaviour

The API failed whilst the Admin UI succeeded

Detailed description

This bug affects IFTAS FediCheck, where we weren't observing the same logic as DomainBlock.rule_for when attempting to create a domain block, which meant an existing block of example would fail the block creation of test.example leaving us out of sync with the Mastodon server (we also weren't handling the error response from the API correctly.

Mastodon instance

No response

Mastodon version

main

Technical details

If this is happening on your own Mastodon server, please fill out those:

  • Ruby version: v 3.2.3
  • Node.js version: v20.11.0
@ThisIsMissEm ThisIsMissEm added bug Something isn't working status/to triage This issue needs to be triaged labels Feb 7, 2024
@ThisIsMissEm
Copy link
Contributor Author

ThisIsMissEm commented Feb 7, 2024

So it looks like the Admin UI will give an error if a higher severity block exists for example, when trying to create a lower severity block for test.example, but if both have the same severity, then the block on test.example can be created, when there's already a rule covering that from example with the same severity:

Screenshot 2024-02-07 at 17 04 57

@ThisIsMissEm
Copy link
Contributor Author

@ClearlyClaire this is what I mentioned on this documentation change: mastodon/documentation#1417 (comment)

When doing a look up for the domain block, or domain federation rule, we need to be comparing the severity and the domain

@ClearlyClaire
Copy link
Contributor

iirc the behavior of the API endpoint being different from that of the admin controller is intentional, with the API being intended to be more straightforward.

But the inability to apply a stricter block on a subdomain through the API is likely not intended, and it sounds like an unnecessary limitation. I'll look into it.

On a side note, wildcards are not supported (and are unnecessary, as any domain block applies to subdomains too).

@ThisIsMissEm
Copy link
Contributor Author

@ClearlyClaire

On a side note, wildcards are not supported (and are unnecessary, as any domain block applies to subdomains too).
This is necessarily only if you want to block the TLD, e.g., .cf

But some *. blocks have made it into people's blocklists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working status/to triage This issue needs to be triaged
Projects
None yet
2 participants