NgSysV.A 深刻で洗練された InfoSys: Firebase D/B ルールとログイン

この投稿シリーズは NgateSystems.com にインデックスされています。とても便利なキーワード検索機能もあります。

最終レビュー日: 2024 年 11 月

1. はじめに

ポスト 2.3 を使用して最初の Firestore データベースを作成したとき、「運用」ルールと「テスト」ルールのどちらを適用するかを尋ねられたことを覚えているかもしれません。当時の提案は、「テスト」ルールを選択する必要があるというものでした。この時点で Firebase コンソールの Firestore ページの「ルール」タブを使用していれば、ルールが次のように設定されていることがわかります:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

ここで、Google はタイムスタンプを使用して、データベースを作成した日から 30 日間データベースへの読み取りおよび書き込みアクセスを許可するデフォルトのルールを作成しました。それは今あなたが望んでいることではありません（そして、いずれにせよ、Googleはそれを変更するようにあなたにしつこく言うでしょう）。そこで、Firestore ルールと、それを使用してデータベースを安全にする方法について詳しく学びましょう。

データベースルール

Firestore の「ルール」を使用すると、データベース呼び出しが行われるたびに Firestore の「ルール ハンドラー」に渡される Firebase リクエスト オブジェクトを参照することで、データベース コレクションへの読み取りおよび書き込みアクセスを制限できます。このオブジェクトには、リクエストを行ったユーザーの詳細、実行されている操作の種類、および現在時刻が含まれます。プロパティの完全なリストを見たい場合は、chatGPT が喜んでこれを提供します。

Firestore ルールの構文を詳しく理解するには、「Firestore ルールの概要」にある Google 独自のドキュメントを参照するのが最善です。ここでは、この投稿シリーズで作成したデフォルト データベースの当面の要件に焦点を当てます。

動作中のデータベース ルールを確認するには、Firebase コンソールの Firestore ページの「ルール」タブを使用して、ルールを次のように変更してみてください。

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

このルールでは、時刻が 2000 年 1 月 1 日より前の場合にのみ、データベース内のドキュメントへの書き込みアクセスが許可されます。したがって、現在タイム マシンで実行している場合を除き、新しいドキュメントを作成することはできません。ドキュメント。

「公開」ボタンをクリックして新しいルールを有効にし (公開が有効になるまでに時間がかかる可能性があるというメッセージは無視しても問題ありません。実際には遅延は最小限であるようです)、Web アプリがどのように反応するかを確認します。

開発サーバーを起動し、http://localhost:5173 で Web アプリを起動します。新しい製品を追加しようとすると、「500: 内部エラー」ページが表示されても、それほど驚く必要はありません。原因を調査するためにターミナル セッションに移動すると、次のメッセージが表示されます:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

Firestore ルールがどのように機能するかを理解できたので、Post 3.1 で作成した製品表示ページと製品メンテナンス ページでこれをどのように使用するかを考え始めることができます。

思い出していただけると思いますが、これらは次の 2 つのルートを提供していました:

• localhost:5173/products-display にある「products-display」ルート。これにより、ユーザーは製品コレクションからすべてのドキュメントを読み取ることができ、
• localhost:5173/products-maintenance にある「products-maintenance」ルート。これにより、ユーザーはコレクションに新しいドキュメントを書き込むことができます。

前提条件として、誰でもに「products-display」ルートを使用して製品ドキュメントを読むことを許可しても構いませんが、許可された個人のみに読み取りを許可する必要があるということです。 「製品メンテナンス」ルートを使用して新しい製品を追加できます。

個人は、Web アプリへの「ログイン」に使用できる「ユーザー ID とパスワード」の組み合わせを発行することで認証されます。この手順では、ユーザーのクライアント デバイス上に永続的な「認証」状態が作成され、ユーザーがデータベースにアクセスしようとしたときに Firestore ルール処理に渡される Firebase リクエスト オブジェクトの一部になります。

次に、Firestore ルールを次のように設定するとします。

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

「ログイン」ユーザーのみが「製品」ページに書き込むことができます。

ここで知っておく必要があるのは、認証状態を作成するための「ログイン」ページの作成方法だけです。ぜひ読んでください!

2. Firebaseログイン

ログイン画面では、将来のシステム ユーザーは個人識別子 (通常は電子メール アドレス) と関連するパスワードの入力を求められます。

その後、システムはユーザーの ID とパスワードを既知の資格情報の安全なリストと照合してチェックします。 Firebase では、このリストはプロジェクトの Firebase コンソールの [ビルド] -> [認証] -> [ユーザー] タブにあります。これを見てください。この機会に、テスト用の電子メール アドレスとパスワードを登録してください (「プログラムによる」登録も可能ですが、ここでは説明しません)。 Firebase が登録に割り当てる「ユーザー UID フィールド」に注目してください。これは、電子メール アドレスの一意の暗号化されたバージョンです。すぐにわかるように、これは Firebase セキュリティ メカニズムの重要な要素を形成します。この画面には、アカウントの削除とパスワードの変更のための機能があることにも注意してください。

ここで、[認証] 画面の [サインイン方法] タブを確認してください。電子メールとパスワードの組み合わせまたは Google アカウントが提供されます。この段階では、電子メール/パスワード オプションのみを有効にすることをお勧めします。

次に、ログイン画面を作成します。以下に示すサンプル コードは驚くほど簡潔です (そしてそのほとんどはスタイル設定です!):

[FirebaseError: Missing or insufficient permissions.] {
  code: 'permission-denied',
  customData: undefined,
  toString: [Function (anonymous)]
}

ログイン スクリプトとログアウト スクリプト用に新しいルート フォルダーと page.svelte ファイルを作成します。ただし、もう少し詳しく説明する必要があるため、まだ実行しないでください。

これらのファイルは、中央の src/lib/utilities/firebase-client.js ファイルから認証変数をインポートすることに注意してください。この中で、Web アプリは firebase-config キーを提示して、認証オブジェクトの作成が許可されていることを Firebase に保証します。これを行う src/lib/utilities/firebase-client.js の更新バージョンは次のとおりです。

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

ここでエクスポートされた app、auth、db 変数は Web アプリで広く必要とされるため、それらを中央の場所に生成することで多くのコードが節約されます。

しかし、ここにあるいくつかの「キラキラ」については説明が必要です。

まず、apiKey などの firebaseConfig プロパティをコード内で 直接 コーディングしていませんが、プロジェクトの .env ファイル (ファイル) で定義した Vite パラメーターを参照していることに注意してください。または「.」が付いたフォルダーは「システム」データであることを示します）。それは次のとおりです:

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

.env ファイルの要点は、アプリケーション コードを含まないファイルに firebaseConfig キーを配置することです。これにより、セキュリティの管理がはるかに簡単になります。しかし、もっと重要なことに集中できるように、今はこのことを脇に置いておきましょう。すべてを説明できることを願って、この投稿の最後にメモを追加しました。

あなたを困惑させるかもしれない 2 番目の機能は、const app = !getApps().length ? です。初期化App(firebaseConfig) : getApp();ライン。これは Javascript の「三項」ステートメントの例です (これを初めて知っている場合は、chatGPT を参照してその仕組みを説明してください)。その効果は次のとおりです:

• Firebase 環境に現在アプリが存在しない場合にのみ、Firebase アプリを初期化します。 Webアプリはユーザーセッション中に頻繁にfirebase-client.jsを参照し、アプリがすでに存在する場合はinitializeApp()が失敗します
• それ以外の場合は、既存のアプリを取得します。

現在は主流に戻り、ログインが成功すると、Firebase が認証されたユーザーの「auth」オブジェクトを作成し、これをブラウザの環境に安全に保管します。したがって、Firebase は、そこから生成された認証トークンを、FireStore データベース サービス リクエストに渡されるすべてのリクエスト オブジェクトに自動的に追加できます。トークン内の情報には、Firebase 認証タブで前に確認した「ユーザー uID」識別子などのプロパティが含まれます。したがって、Firestore は、書き込みを許可する: if request.auth != null などのルールを適用する方法を決定できます。

これはすべて、クライアント側の Firestore アクティビティが時計仕掛けのように機能することを意味します。ログインすると、データベースのセキュリティに関するすべての懸念事項が Firestore ルールによって処理されます。

しかし、そこには障害があり、実際には大きな障害があります。 Firebase がブラウザ環境に組み込んだ「auth」オブジェクトは、inventory-maintenance/page.server.js などのサーバー側のページでは使用できません。

これは簡単に実証できます。

1. 誰でも製品コレクション内のすべてを読み取ることができるが、認証された人のみがドキュメントを作成できるようにする新しい Firestore ルールを公開します
   

   match /{document=**} {
     allow read, write: if request.time < timestamp.date(2024, 10, 31);
   }
   

2. /login ルートを使用してログインすると、「Google でログインしています」というアラートが表示されます。

3. /products-display ページを起動します。 Firestore ルールにより、誰でもがすべてを読み取ることが許可されているためです。したがって、ページには、以前とまったく同じように、登録されている製品の現在のリストが表示されます。

4. 製品メンテナンス ページで新しい製品を追加してみてください。ああ！エラー!
   

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

ここで起こっていることは、ブラウザの「squirreled」認証変数とその親 Firebase セッションの残りの情報がサーバー上の Firestore で利用できないということです。したがって、そこでは request.auth が定義されていないため、Firestore ルールは失敗します。

Google は、クライアント側での生活をとても楽しくする優れたセッション管理機能のサーバー側バージョンを Firebase に提供することを拒否したという立場です。現在、コードは Firestore Client API を使用しています。 Firestore データベースが Firebase 認証セッション変数を参照するコレクションに「ルール」を設定しているサーバーでは、クライアント API ではなく Firestore Admin API を使用する必要があります。 Admin API の呼び出しでは Firestore ルールがチェックされないため、認証が定義されていない場合でも失敗しません。ただし、Admin API を使用すると、次のような影響が生じます。

• Admin API はさまざまな「呼び出し署名」を使用します。サーバー側でデータベースの読み取り/書き込み操作を実行するために使用する管理 API 関数のシーケンスは、クライアント バージョンとほぼ同様ですが、使用する構文が異なります。
• Admin API では、自分で作成したコードを使用して、必要なユーザー データを取得する必要があります。 uID や userName などを配信するために非常に貴重な auth.currentUser オブジェクトを便利に提供していたクライアント側の Firebase セッションは、サーバー側では利用できなくなりました。交換品を提供するには、お客様ご自身で手配する必要があります。

うめき声。代替手段はありますか?次の 2 つの投稿は次のとおりです:

1. 「ルールに優しい」バージョンの Web アプリを開発して問題を回避する方法。この結果、パフォーマンスの低下 (サーバー側のコードの実行速度が向上するため)、セキュリティの低下 (クライアント側のフォーム検証が安全でないため)、SEO の見通しの低下 (Web スパイダーがクライアント側のコードのインデックス作成に対する熱意を低下させるため) が発生します
2. あるいは、Web アプリの完全な「クライアント サーバー」バージョンを開発する方法について説明します。これにより、最高のパフォーマンス、セキュリティ、SEO が得られますが、Firebase ユーザー セッションの取り決めの喪失によって残された機能のギャップを埋めるために、さらに別のテクノロジーの波を交渉する必要があります

3. 結論

これは不幸な結末を伴う大変な道のりでした。ただし、エネルギーを持って読み進めていただければ幸いです。

開発者としての観点からすると、ブラウザのインス​​ペクター ツールを使用して完全にデバッグできるため、ルールに適したコードは非常に喜ばしいものとなるでしょう。前述したように制限はありますが、多くの単純なアプリケーションでは完全に満足できるものになる可能性があります。

クライアント/サーバー バージョンにはいくつかの新しい課題がありますが、主流の開発実践における貴重な経験が得られ、真に優れたパフォーマンスを実現します。

追記 - この「.env」ビジネスとは一体何なのでしょうか？

奇妙に思われるかもしれませんが、これはすべて Microsoft の「Github」バージョン管理ソフトウェアから始まります。これは、ソースのコピーを個人の Web ベースのリポジトリにコピーできる無料の Web アプリです。これは業界標準となっており、「git と Github の優しい入門」で詳しく学ぶことができます。

その主な目的は、同じプロジェクトで並行して作業している開発者チームのアクティビティを統合することです。しかし、あなたは、個人プロジェクトの開発や継続的な強化中に、コードの「チェックポイント」スナップショットを安全な場所に置きたい場合があるため、これを使用することに興味があるかもしれません。 .

問題は、ソース コードに埋め込まれた機密キーが誤って Git リポジトリに保存されることが非常に簡単であることです。リポジトリは「プライベート」としてマークできますが、セキュリティは保証されません。

その解決策の 1 つは、プロジェクト キーがコード ファイルとは別に保持されるように調整することです。こうすることで、Git にコピーする必要がなくなります。 Firebase キーを libutilitiesfirebase-client.js ファイルに配置すると、キーが複数の page.server.js ファイルにコード化されなくなるため、ここでは役に立ちました。ただし、中央の firebase-client.js には、リポジトリに保存したいコードがまだありました。 env ファイルを使用すると、最終的にキーからコードを解きほぐすことができます。 .env キーはプロジェクトに残りますが、このファイルをコード リポジトリにコピーする必要はなくなりました。したがって、これを .gitignore ファイルに追加して、どのファイルを除外するかを Git に指示することができます。

Svelte がプロジェクトを初期化したときに .gitignore ファイルを作成し、ソースコード チェックポイントには存在しない Vite システム フォルダーの詳細がすでに含まれていることがわかります。 「.env」ファイル (およびそのファイルの編集履歴) がすべての Git コミットから確実に除外されるようにするには、次のエントリを追加します:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

これを実行すると、VSCode ワークスペース ディレクトリの /.env 行が「グレー表示」になることに注意してください。これにより、このファイルが Git コミットによって Web 上に公開されないことが視覚的に保証されます。

以上がNgSysV.A 深刻で洗練された InfoSys: Firebase D/B ルールとログインの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。