管理者認証

SubLane は、グローバル ローカル ログイン ID と、所有者、管理者、またはメンバーの役割を持つワークスペース メンバーシップを使用します。最初に実行した管理者が最初のワークスペースを所有します。セッションはワークスペース間で共有されますが、権限の範囲は選択したワークスペースに限定されます。見る メンバーアクセス 権限、招待リンク、アカウントのライフサイクルについて。パーソナル ゲートウェイ キーは別の方法で入手できます。 API キーのワークフロー。パスワードのライフサイクルとローカル回復コマンドについては、「 チームコントロール.

初回セットアップ

SubLane を通常どおり起動し、UI を開きます。データベースに管理者がいない場合は、 /setup に、セットアップ フローを説明するウェルカム ページを示します。選択 セットアップを開始する 開く /setup/admin。まず管理者のユーザー名とパスワードを入力し、次に別の手順に進んで最初のワークスペースに名前を付けます。 2 番目のステップを送信すると、両方のレコードが作成され、サインインします。個別の初期化キーは必要ありません。

セットアップ ウィザードでは、 /setup/admin;更新すると管理者ステップに戻ります。どちらのセットアップ ルートも初期化後は使用できなくなります。サインアウトした訪問者はログインに移動し、サインインしたユーザーはロールに適したワークスペースに移動します。オンボーディング状態やアカウント認証情報はブラウザーのストレージには保存されません。

他のユーザーにインスタンスを公開する前に、ローカルでセットアップを完了してください。初期化が完了するまで、セットアップ ページにアクセスできる人は誰でも最初の管理者を作成できます。デフォルトのリスナーと Compose ホスト ポートはループバックにバインドされたままになります。

ユーザー名には、文字または数字で始まる 3 ～ 32 個の ASCII 文字、数字、アンダースコア、またはハイフンが使用されます。大文字と小文字は区別されず、小文字で保存されます。新しいパスワードには 8 ～ 20 個の Unicode 文字が使用され、トリミングされません。ログインでは、以前の 128 文字の制限まで既存のパスワードが引き続き受け入れられます。

管理者、最初のワークスペース、所有権メンバーシップ、および最初のセッションは 1 つのトランザクションでコミットされます。保護された挿入により、同時セットアップ要求によって最初の管理者が置き換えられることがなくなります。トランザクションが成功すると初期化が終了し、サービスを再起動してもサービスは再度開きません。

統合されたプレリリース スキーマより前のレガシー開発データベースは、自動的にはアップグレードされません。新しいインスタンスを開始する前に、古いディレクトリを保存してください。すでに統合スキーマ上にあるデータベースは、追加の招待移行を受け取ります。残り物 setup.key 以前の開発ビルドからのものは、新しいインスタンスでは使用されません。

データベースの削除または置換は、パスワード回復手順ではありません。ローカルを使用する reset-admin-password --password-stdin 既存の管理者用のコマンド、または「認証済みの変更/リセット フロー」で説明されています。 チームコントロール.

セッション

• ログインでは、HttpOnly、SameSite=Lax、パスルート Cookie 内の不透明で暗号的にランダムな 256 ビット トークンが使用されます。
• SQLite には、トークンの SHA-256 ダイジェストのみが保存されます。
• セッションは 12 時間後に期限切れになり、スライド更新は行われません。
• ユーザーごとに最大 5 つのセッションが保持されます。新しいログインは、そのユーザーの最も古い余分なセッションのみを置き換えます。
• ログアウトすると、成功を報告して Cookie をクリアする前に、SQLite の現在のセッションが取り消されます。
• セッションは通常のプロセスの再起動後も存続します。
• ブラウザーはテーマと言語設定をローカルに保存しますが、セッション トークンは保存しません。

UI は、保護されたページを表示する前に、サーバーのセッション状態を待機します。フォーカス時に状態を定期的に再チェックし、保護された API リクエストが期限切れのセッションを報告するとログインに戻ります。ログアウトすると、保留中のクエリがキャンセルされ、プライベート キャッシュ データがクリアされます。バックグラウンド セッション チェックでは、ユーザー ID またはロールが変更されたときにプライベート データも消去されます。

リバースプロキシとHTTPS

ネットワーク展開の場合、リバース プロキシで HTTPS を終了し、外部から見える起点を設定します。

SUBLANE_PUBLIC_URL=https://sublane.example.com ./bin/sublane

オリジンには、スキーム、ホスト、およびオプションのポートのみが含まれている必要があります。パス、資格情報、クエリ パラメータ、およびフラグメントは拒否されます。 HTTPS パブリック オリジンでは、内部プロキシ接続が HTTP を使用している場合でも、セキュア Cookie が有効になります。

この設定を行わないと、同一オリジン チェックではリクエストのホストと実際の TLS 状態が使用されます。転送されたホスト、プロトコル、ピアのヘッダーは暗黙的に信頼されません。 Vite は、ローカル開発用に元のホストを API プロキシ上に明示的に保存します。

バックエンドをループバックまたはプロキシの背後にあるプライベート ネットワークにバインドしたままにします。ネットワーク アクセスには HTTPS を使用します。ローカル HTTP のデフォルトは開発用です。

リクエストの保護とリソース制限

すべての管理ルートは次のとおりです /api/ 明示的な認証エンドポイントを除き、デフォルトで有効な管理者セッションが必要です。個人的 /api/keys そして明示的な /api/me/requests, /api/me/password, /api/me/limits そして /api/me/usage エンドポイントは両方のロールに対してセッションで保護され、所有権が強制されます。メンバーは自分のセッション状態を読み取ってサインアウトできますが、管理者管理 API にはアクセスできません。静的 SPA アセットは公開されたままになります。アプリケーション バンドルをレンダリングしても、管理データへのアクセスは許可されません。

ミューテーションにはまったく同じオリジンの Origin ヘッダーが必要で、クロスサイトのメタデータのフェッチは拒否され、JSON のみが受け入れられます。認証ボディは 4 KiB に制限されており、読み取り期限は 5 秒です。

セットアップ、ログイン、および招待登録には、接続ピアあたり 1 分あたり 5 回の試行制限と、1 分あたり 60 回の試行というグローバル制限が共有されます。 Responses スロットル時の Retry-After が含まれます。リミッター状態は 1,024 ピアに制限されており、プロセスローカルであるため、再起動するとカウンターがリセットされます。リバース プロキシの背後では、明示的な信頼できるプロキシのサポートが導入されるまで、クライアントはプロキシのピア バジェットを共有します。

パスワードの導出は、2 つの同時操作に制限されています。 Argon2id は 19 MiB、2 回の反復、および 1 つのレーンを使用します。 OWASP パスワード ストレージ ベースライン。これらの制限は、プロセス全体のメモリを保証するものではありません。

API

セットアップとログインの承諾 username そして password;セットアップ フォームは、送信する前にパスワードの確認をチェックします。ログアウトは空の JSON オブジェクトを受け入れます。認証済み状態の応答には、永続化されたユーザー ID、ユーザー名、および admin または member ロールに含まれており、トークンやパスワード ハッシュは決して含まれません。エラー応答には、ローカライズされたフロントエンド メッセージの安定したコードが含まれています。

コマンドライン HTTP クライアントの場合は、正しい Origin ヘッダーと JSON コンテンツ タイプを明示的に指定します。認証情報をシェル履歴に保存したり、バグ レポートで共有したりしないでください。

二要素認証 · パスキー

/preferences

パスワードでのログインに認証アプリのコードを追加します。すべてのワークスペースで有効です。 指紋、顔、デバイスの PIN でパスワードなしでログインできます。本人確認済みのパスキーは二要素認証も満たします。最大 10 個登録できます。

安全な場所に保管してください。各コードは認証コードの代わりに一度だけ使用できます。再表示されません。再発行すると以前のコードは無効になります。

パスキーには HTTPS または localhost と WebAuthn JSON 対応ブラウザーが必要です。