Post
Hey @evan, sorry to bother you here and not on the github repo, but I have a question regarding tags.pub.
Do you by any chance only return response code 400 on fetches with an invalid HTTP-Signature?
Full error looks like this (when loading: "https://tags.pub/user/activitypub"):
> status received : {"type":"about:blank","title":"Bad Request","status":400,"detail":"No created timestamp provided"}
@mariusor I think what I try to do is:
401 - no authentication provided
403 - authentication is present and valid, but not authorized
400 - authentication is present but not valid, like missing fields
Does that seem right to you?
Also, I think the `created` timestamp is necessary for preventing replay attacks. It's pretty important!
@evan I think missing fields should also signify an unauthorized request... I'm not an expert what a "bad request" means, but I would interpret it as "the request does not have all necessary components for the server be able to compose a valid response".
An authorization header is not part of that in my opinion, but I'm willing to entertain the idea. :)
(Also I'm pretty sure I'm appending the created timestamp... but maybe I missed to test for that... I'll get back to you if it's my problem)
@mariusor I think you might be right. I think if the request is invalid, it should return 401 with the WWW-Authenticate header and the required headers.
@mariusor Just as a note, it should also accept RFC 9421 signatures, if you'd prefer to use them.
@evan yep, my client double knocks with RFC9421 and Draft HTTP signatures. Triple knocks actually in the case of key fetches, where the third time is tried w/o a signature.
@mariusor for key checks, I think you should go unsigned first!
@evan probably, but the way code is structured I'm using the same client for all requests, including key fetch. I might find a way to separate between Activity requests and key fetches at some point, but until then it's kinda like that.
My logic was that in the case of a public resource most servers would just serve it even with an invalid authorization mechanism... but I guess that if you choose to fail early, that's no longer the case...
@evan in GoActivityPub an invalid signature returns a token "Anonymous" Actor entity that can be verified for permissions against the ACLs of the resource being requested. And in the case of public objects the check succeeds.
Perhaps I got lucky until now mostly relying on my own architecture for both clients and servers...
Install bonfire.cafe
Get the full app experience
