たい

が実装しているサービス？の説明をします

全然明確な書き方になってなくて完全にメモなのでちょっとアレです

2021/10/9 17:42

/js-fetch-proxy/ScrapboxのUserScriptは、なぜ外部リソースを読み込めな（い/かった）のかでかなりわかりやすく説明できたっぽい

/js-fetch-proxy/node-bitmap-proxyとかもどうぞ

外部サーバーの準備は必要になりますが、送受信情報を全て画像に埋め込んでやり取りすることで、外部との通信がほぼなんでも可能になります

簡単にいうと、 https://my.proxy.server/url/https://target.url みたいなsrcを画像に設定して、返ってきた画像から通信情報を読み出します

ブラウザ→自前のサーバー→目的のサーバー→自前のサーバー（ここで画像にエンコード）→ブラウザ（画像から読み込み）

データを画像に変換して通信するとは……その発想はなかった

めちゃくちゃ強引だw

なんだかんだ他の形式でも通信できると思うんで、極言すればCSPのconnect-srcの制約は、CSPの各項目の「最小の制約」と一致するんだと思います

今回は img-src がワイルドカード * 指定なので、connect-srcも実質ワイルドカード制約

実際CSSのコメント欄に情報を書き込んで送付とか普通にできそうだし、真実っぽい

/public-minaph/CSPのconnect-srcは、セキュリティとしてはほとんど意味がないにちょっと書いた

現状、CSPの突破自体はすでに実行できていて、あとは利便性の向上のためにtodoがいくつか

API keyなどの秘匿情報をUserScriptに書けるようにする（事前に暗号化する仕組みを導入する）

一連の通信を関数に包んで、使いやすくする

長いpostメッセージにも対応できるようにする

従来のブラウザ拡張機能を使ったやり方と比べると、「誰かがサーバーをセットアップさえすればみんな使える」という点が長所です

例えば「井戸端からのアクセスは許可」とかでサーバーをセットアップすればOK

スマホユーザーも恩恵を受けられます

Scrapboxが画像のCSPを制限しない限りは、今後も有用なアプローチのはず。。。

ちなみに今僕がちょっと忙しいので、完成は少し先です

2021/10/06

仕様の決定で迷うところがあったので、発展させてjs-fetch-proxyというのを作り（提唱し？）ました

ブラウザでのリクエストを、プロキシサーバーで代理実行する、というコンセプトです

画像通信は脇役にしちゃいました