Repository navigation
feat: Basic auth - #7
Merged
Merged
Conversation
Unlocks the servers people actually ask about. Nextcloud and Synology hold their own credentials, so until now there was no way to point the extension at one — the compatibility table said as much. The credentials are stored in cleartext in chrome.storage.local. An extension has no storage keyed to the user, so encrypting them would mean keeping the key next to them; obfuscating it would only look safe. Instead the settings page states plainly where they are stored, and the mode is restricted to https:// shares so they are never sent over the wire in the clear. Two details worth naming: - Credentials are UTF-8 encoded before base64, per RFC 7617. Passing a non-ASCII password straight to btoa throws. - A redirect to another origin is rejected. fetch does not drop the Authorization header across a redirect, so following one to an unrelated host would hand it the credentials. test/live.mjs now goes through the extension's own auth instead of building an Authorization header itself — otherwise the integration test would be exercising test code rather than the shipped implementation. Nextcloud joins the compatibility matrix (149/149). It exercises two paths the other servers don't: Basic auth, and serving from a subpath, which puts the baseurl handling under test. dufs --auth is there too as a light check that doesn't need a multi-minute install. The readiness probe now waits for the exact request the test will make, rather than for any response at all, so Nextcloud's installer returning 503 no longer counts as ready. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
なぜ
Nextcloud と Synology はサーバ自身が資格情報を持つので、これが無いとそもそも接続できない。互換表にも「Basic 認証が要るので入れられない」と書いてあった行がそれ。
保存方針（先に確認した点）
資格情報は
chrome.storage.localに平文で載る。拡張にはユーザーに紐づく保存先が無いので、暗号化しても鍵を同じ場所に置くことになる。難読化して安全に見せるより、設定画面に平文と明記し、https://の共有にしか設定できないようにした（平文で線を流させない）。アプリパスワードを発行できるサーバではそちらを使うよう、フォームに書いた。
実装で名前を出しておくべき点 2 つ
btoaは Latin-1 しか受け付けないので、非 ASCII のパスワードをそのまま渡すと例外になる。先に UTF-8 に符号化してから base64 しているfetchはリダイレクトを跨いでもAuthorizationを落とさないので、追った先が無関係なホストだと資格情報がそこへ渡るテスト側の変更
test/live.mjsが Authorization を自前で組み立てていたのを、拡張のcreateAuthを通すように変えた。そうしないと結合テストが検証しているのがテスト側のコードになってしまう。互換表
Nextcloud 34 が 149/149 で通過。他の実装と踏む経路が違うのが価値で、Basic 認証が必須なうえサブパス配信 (
/remote.php/dav/files/<user>) なので baseurl の処理も同時に通る。29MB の PDF に対する Range 検証も含む。dufs --authも入れた（Nextcloud は初回インストールに数分かかるので、軽い確認用）。compat.shの起動待ちを「何か応答した」から「これから投げるリクエストが通った」に変えた。前者だと Nextcloud のインストール中の 503 を掴んで先へ進んでしまう。その他
toProviderErrorで 401 →ACCESS_DENIED（今まではFAILEDに落ちていた）'basic'を「未知の認証方式」の例に使っていたので'digest'に差し替え🤖 Generated with Claude Code