ActivityPub requests on routes which do not support activitypub
are now replying with HTTP status code 406 "Not Acceptable".
ActivityPub clients are required by the W3C TR to set the `Accept`
header. If this accept header is detected on an unexpected route,
the whole request will be aborted with the status code above.
This is an additional measure for clients who might not be aware of
having to check the content-type header of the reply.
Ref: https://github.com/w3c/activitypub/issues/432
Changelog: Security
Enforces HTTP signatures on object fetches, and rejects fetches from blocked
instances. This should mean proper and full blocking of remote instances.
This is now default behavior, which makes it a breaking change. To disable
it (mostly for development purposes), the configuration item
`allowUnsignedFetches` can be set to true. It is not the default for
development environments as it is important to have as close as possible
behavior to real environments for ActivityPub development.
Co-authored-by: nullobsi <me@nullob.si>
Co-authored-by: Norm <normandy@biribiri.dev>
Changelog: Added
The default of the library used is to require either of the "date" or
"x-date" headers. It does not seem sensible to pass on this default.
It may be to fix federation with another software but that software
should be considered broken, and it does not seem reasonable to
potentially get an outdated signature just to fix federation with some
buggy software.
* add id for activitypub follows
* fix lint
* fix: follower must be local, followee must be remote
Misskey will only use ActivityPub follow requests for users that are local
and are requesting to follow a remote user. This check is to ensure that
this endpoint can not be used by other services or instances.
* fix: missing import
* render block with id
* fix comment