基本コンセプト
TODO（内部向け・リリース前に対応して削除）
Section titled “TODO（内部向け・リリース前に対応して削除）”Keelson は何をしてくれるのか
Section titled “Keelson は何をしてくれるのか”Keelson は、社内やチームで共有するアプリを安全に公開するための実行基盤です。
ユーザーはアプリそのものの開発に集中し、公開・認証・共有に必要な仕組みは Keelson が引き受けます。このページでは、その考え方を説明します。
リクエストはどのようにアプリへ届くのか
Section titled “リクエストはどのようにアプリへ届くのか”Keelson にデプロイされたアプリには、ユーザーのブラウザから直接アクセスが届くわけではありません。すべてのリクエストは、まず Keelson Proxy を通ります。
内部では何が起きているのか
Section titled “内部では何が起きているのか”ユーザーが Keelson にデプロイされたアプリの URL を開くと、リクエストは次の順序で処理されます。
- 公開URLから、どのアプリへのアクセスかを特定する
- Keelson Proxy がログイン状態を確認する
- アプリへのアクセス権限を確認する
- 許可された場合のみ、リクエストをアプリへ転送する
- アプリのレスポンスをユーザーに返す
重要なのは、認証とアクセス制御の判断がアプリ本体の外側で行われることです。そのため、アプリ開発者は認証画面やセッション管理を毎回自前で実装しなくても、共有前提のアプリを安全に公開できます。
Keelson では、認証とアクセス制御の責務をアプリ本体の外側に分離しています。アプリは業務ロジックに集中しつつ、共有時のセキュリティはプラットフォーム側で一貫して扱えます。
なぜ認証をアプリに書かなくてよいのか
Section titled “なぜ認証をアプリに書かなくてよいのか”Keelson では、アプリをデプロイした瞬間からログイン保護が有効になります。これを Security by Default と呼んでいます。
- セキュリティは後付けではなく、最初から組み込まれている
- 「動いた後に認証を足す」のではなく、「公開した時点で安全」
- Quickstart で体験した、シークレットウィンドウでのログイン画面がこの仕組みの結果
Keelson が単なるホスティングではなく、社内アプリのための実行基盤である理由がここにあります。
Keelson はアプリの入口でログイン保護とアクセス制御を提供します。アプリ内部の業務ルールに基づく制御が必要な場合は、アプリ側で追加の実装を行います。
責任分界: アプリが担うこと / Keelson が担うこと
Section titled “責任分界: アプリが担うこと / Keelson が担うこと”Keelson を使うとき、開発者が関わる範囲と Keelson が引き受ける範囲は明確に分かれています。
| アプリが担うこと | Keelson が担うこと |
|---|---|
| UI | デプロイ先の用意 |
| 業務ロジック | 公開URL |
| API | ログイン保護 |
| データ処理 | アプリへのアクセス制御 |
| 実行環境の管理 |
この分担があるため、アプリの開発者はインフラやセキュリティの構築に時間を割く必要がありません。
なぜ Keelson は社内・チーム共有に向いているのか
Section titled “なぜ Keelson は社内・チーム共有に向いているのか”Keelson は、ローカルで一人だけが使うアプリのための基盤ではありません。チームや社内で安全に共有することを前提に設計されています。
そのため、以下の機能がプラットフォームに組み込まれています。
- 公開URL — デプロイするだけでチームに共有できるURLが発行される
- ログイン保護 — 許可されたメンバーだけがアクセスできる
- メンバー管理 — 誰がどのアプリにアクセスできるかを制御できる
これらの詳細は、以下のページで説明しています。
まずアプリを動かし、細かい設定はあとから足す
Section titled “まずアプリを動かし、細かい設定はあとから足す”最初はアプリを載せて動かすことに集中すれば十分です。
Keelson の設定は段階的に進められます。クイックスタート で触れた体験は最小構成の入り口であり、必要に応じて以下のような設定をあとから追加できます。
- keelson.yaml リファレンス — アプリの詳細設定
- 環境変数 — 実行時の設定値
- カスタムドメイン — 独自ドメインの割り当て
- IP許可リスト — アクセス元の制限