Problem/Motivation

I run an Akkoma instance (Pleroma fork). I have "Authorized Fetch Mode" enabled on it, which requires HTTP signatures on AP fetches.

When doing a little testing between Drupal and my Akkoma, I got this error logged on the Drupal end:

Signature verifying exception: Client error: `GET https://mycrowd.ca/users/fluglbrrzzkj3332lz` resulted in a `401 Unauthorized` response: Request not signed

(mycrowd.ca is the Akkoma instance)

Steps to reproduce

I was trying to follow the Drupal user from a test account on the Akkoma instance.

I have the feeling that with Authorized Fetch on, this may not work presently.

The context plugin suffers from this problem, but also fetching simply author information.

More background: https://seb.jambor.dev/posts/understanding-activitypub-part-4-threads/#t...

swentel: Got it myself as well trying to follow https://reentry.codl.fr/users/apod
Patch for AP library: https://github.com/landrok/activitypub/issues/49

Remaining tasks

Add an 'instance' actor with public/private keys so we can sign those requests.

More info:
https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/
https://seb.jambor.dev/posts/understanding-activitypub-part-4-threads/ (The Instance Actor)

Issue fork activitypub-3420731

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

kinetix242 created an issue. See original summary.

swentel’s picture

swentel commented

It doesn't ring a bell, so yes, we might miss something here, although I have no idea what this Authorized Fetch Mode means exactly.

Is there any documentation about this somewhere that you know of? I hope we're able to use the Nodeinfo of the pleroma instance to figure out that also GET requests to a user to fetch the AP information needs to be signed (hopefully also just like we're already signing outbox requests).

kinetix242’s picture

kinetix242 commented

Some info on it: https://hub.sunny.garden/2023/06/28/what-does-authorized_fetch-actually-do/

I am curious if my Activitypub settings could cause the problem - I have the site-wide user set to 0, which I might have accidentally done, but I haven't seen information / documentation on what the value should be.

kinetix242’s picture

kinetix242 commented

I'll just add that I've created a separate user for Activitypub, changed the site-wide user to that user ID (5), and ensured that authenticated users can publish to the site-wide actor.

Same result when trying to do the follow from the Akkoma instance.

I hope my additional comments are somewhat helpful. Please let me know if there's more I can do.

swentel’s picture

swentel commented

Ok, that post is good enough to dive into it as it has links to issues/code/documentation so I can figure out.

As far as I can see, this isn't necessarily part of the ActivityPub protocol, but I guess it can't hurt to enable this.

kinetix242’s picture

kinetix242 commented

I don't know if this will be at all helpful about the topic, but it looks like there's a draft report for "ActivityPub and HTTP Signatures" at https://swicg.github.io/activitypub-http-signature/#survey-of-standards-...

I apologise for the noise if this isn't helpful.

swentel’s picture

swentel commented
Assigned: Unassigned » swentel

Looking at this, this is also a problem for simply getting the actor information to get the avatar.

mradcliffe’s picture

mradcliffe
he/him
Primary language English
commented

I pretty much have to double-knock or triple-knock all requests now.

1st - unsigned for GET
2nd - signed via RFC 9421
3rd - signed via cavage-12 draft

Basically my solution is to try/catch and recursively call with a different signature option, and depending on the implementation, a different response code is returned when a signature is needed (or an instance doesn't support a signature implementation). These are 401, 403, and 406. wafrn, until recently, returned a 200 with text/html representation of the document, if a signature was required for the actor, but I recently fixed this for them.

swentel’s picture

swentel commented
Issue summary: View changes
swentel’s picture

swentel commented
Issue summary: View changes
swentel’s picture

swentel commented
Issue summary: View changes
swentel’s picture

swentel commented
Issue summary: View changes
swentel’s picture

swentel commented
Title: Authorized fetch may be missing? » Add support for authorized fetch

swentel opened merge request !67

swentel’s picture

swentel commented
Version: 1.0.0-alpha18 » 1.0.x-dev
Category: Feature request » Task

  • swentel committed bae252e6 on 1.0.x 
    Issue #3420731: Add support for authorized fetch
swentel’s picture

swentel commented
Status: Active » Fixed

Yes! Coming in the next release, actor and status requests are now signed with the 'instance' actor which is now available. When installing, or upgrading, you will need to generate keys for this special 'instance' actor at 'admin/config/services/activitypub'. I can finally follow users on instance which have this 'feature' turned on!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.