おひとり様サーバーのGETリクエストを署名付きで投げるようにした。

今のところ、特に問題が出てるようには見えない。

前々から気になってたところ。

actor情報や投稿を取得するために、アクセスすると401や403で弾かれることがあって、それってリモートサーバーからのアクセスを拒否してるのかなあ、ぐらいに思いつつもなんかひっかかってた。

GETリクエストにひょっとするとSignatureが必要なわけ？と。

でも、POSTと違ってGETだよ？Body（content、本文）もないのに、いったい何に対してサインする？んなもんないよなあ、とも思ってた。

2023Fediverseアドベントカレンダー第3会場19日目の黒ヰ樹さんの記事

「DenoとHonoでThreadsのContent-Type: application/activity+jsonをGETする」

当初ActivityPubのHTTP Message Signaturesはhostとdateを認証するPOSTのみで使われてきました。

ThreadsのContent-Type: application/activity+jsonをGETするにはこの署名が必須なので、Threadsをフォローできないサーバーがあったりなかったりしたんですね。

↑こちらに詳細があった（感謝）

GETでのHTTP Signatureは

(request-target)

host

date

の３つを署名対象にすればOKということらしい。

（ひょっとしてわたしが知らなかっただけで、100年前からの常識だったのかな？）

この署名付きでGETを投げて403で弾かれることがあるけど、401は今のところない。これで大丈夫っぽい。

HTTPのレスポンスは。

401 認証できない

403 認証できるけど権限がない

404 そんなファイル、ディレクトリはそもそもない

403を返すと「そんなファイル」はある、ということを自白してるのでセキュリティ的にあえて404を返してることがある。なので、403と404は同じで原因の特定ができないとしても、401が返ってくるのはこちらに何らかの問題がある、ということ。

表示が無駄に重くなるだけなので、うちのおひとり様サーバーでは、400番台が返ってくるサーバーはリストに登録してアクセスしないようにしてた。

とりあえず。この対応で401は回避、できるかな。

今日は3回目のゲ謎。哭倉村。

ほんと、今年No.1だなー。

[12/21 14:07:43]追記。

401でエラーを出してた某サーバーのactor情報がこの変更で取得できたので、やっぱりGETにSignatureがなかったのが問題だったのか…。

[2024/01/09 11:46:23]追記。

HTTP SignatureをつけてGETしても403で弾かれるサーバーがあった。

いろいろ試してみたところ、お相手のHTTP HeaderのkeyIdのURLについてる「#main-key」が原因っぽかった。

お相手からのポストの署名を検証するためにPublickeyを取得する必要があって、Publickeyを取得するにはこのkeyIdのURLにリクエストを投げてPersonのJSONをもらわなきゃいけない。

Mastodon系などはkeyIdのURLにそのままGETリクエストしていて問題はなかった。んだけど、なんか「#main-key」付きって微妙なURLだなあ、とか思ってたこともあって、試しにURLの「#main-key」を削除してリクエストしたら問題なく200が返ってきて、無事JSONを取得できた。

だけど、今度はそれはそれで、keyIdのURLに「#main-key」なんてつけないで欲しいよなあ。「keyId」の意味がないのでは？