federation/in: improve reply on requests from blocked domains #940
No reviewers
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#940
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "Oneric/akkoma:httpsig-mrf-reply"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Previously all such requests led to '401 Unauthorized'
which might have triggered retries.
Now, depending on whether MRF info can be disclosed, either an
informative '403 Forbidden' response is sent, or a success or
non-existence of the requested object is faked.
Notably this change also now causes all signed fetch requests from
blocked domains to be rejected even if authorized_fetch isn’t enabled.
Fixes: #929
Imho rejecting requests from blocked domains makes sense regardless of auth_fetch, but then again I always enable auth_fetch anyway.
If instead signed GET requests from blocked domains should still continue to succeed, the following can be used (and the added tests need to be adapted):
57c129d83f
to20abc658d7
404 is indeed the correct way to hide an unauth, i agree with this decision
though should we actually care about
transparency
? i see why you've done it, but it might make sense to just apply the 202 or 404 model everywhere, and give out as little information over AP as we can get away with20abc658d7
to0a9e7d4712
sure, i don’t mind always using 202/404. Updated the commit to do just that