Bibiでクエリー付きのEPUB URIにアクセスしたい
CloudFrontとかFirebase Storageで、認証用のクエリーが付いたURIからファイルを読み込みたい
/bibi/?book=page-blanche%3Ftoken=xxxとしてアクセスしたい
現状、単純にこれにMETA-INF/container.xmlを文字列結合してるから変なURIになる
Package Documentのitem@hrefがtoken=xxx付きになっているというのが正しいシステムだろうか
%3Ftoken=xxxじゃなくて&token=xxxだったらBibiは配慮するだろうか
しない。クエリー部分は捨てて/META-INF/container.xmlにアクセスする
なのでパッチを当てる必要は必ずある
選択肢
page-blanche&3Ftoken=xxxの時に?token=xxxを各ファイルアクセスに付ける
だめか。トークンがファイルごとに違うのが一般的
page-blanche&token=xxxをそのまま/META-INF/container.xmlその他のファイルアクセスにもつける
同上
HTTPエージェントにオプションで「追加クエリー」を渡せるようにする
ファイルごとに別々に
Package Documentのitem@hrefを書き換えて全部トークン付きにする
META-INF/container.xmlとPackage Documentへのアクセス時は別途ケアする必要がある
↓に一般化できるからそっちの方がよさそうだな。実装コスト変わらんだろうし
HTTPエージェントにオプションでコールバックを渡せて、そこでトークンを付与できる
或いは「FirebaseとかのAPIを使ってトークンを取得する」という関数を登録する
これかなあ。
どこでHTTPリクエストしてるのか?
Source.URIというのをチェックしてるから、これにgetDownloadURLの結果を入れたらいいかな
ではO.downloadの引数はどう決まってる?
B.Containerは?
O.extractはどこから呼ばれてる?
O.srcに介入するのもいいけど、これ同期関数だから、getDownloadURLはPromise返すから相性悪い。
O.downloadに介入するのがよさそう
設定はどこでやるのがいいか?
プラグインの仕組みあったっけな……
Service Workerで無理やりトークンを付けて回る
最後の手段?
Bibiのコードを読み解いてパッチを当てる苦労を考えると結構いい気がしてしまう……。
案外今は当たり前の手段? 若い人の感覚を知りたい。
考えると結構筋がよさそうに思えるが
メインスレッド用のコードだけ見てると魔法のように見えちゃうのがよくない? いいよね。どうせフレームワークとかライブラリーとか既に魔法でしょ。
Service Workerコードの更新についてノウハウないのが懸念ではあるが、これをきっかけに貯めればいいか。
初回アクセス時にService Workerを有効化しないといけないかな。無理やり
うまくいかんなあ。Service WorkerのなかでgetDownloadURLするとPromiseがpendingのまま何も起こらない