NgSysV.A 本格的で洗練された InfoSys: クライアントサーバー バージョン

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

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

1. はじめに

ポスト 3.3 では悪いニュースがいくつかありました。ログイン ユーザーに関する情報を提供するためにクライアント側で使用されていた Firestore 認証オブジェクトがサーバー側では利用できません。これにより、次のような結果が生じます:

• サーバー側のデータベース コードでは Firestore Admin API を使用する必要があります。これは、認証が利用できない場合、認証を参照するデータベース「ルール」に従って呼び出しを行う Firestore クライアント API コードが失敗するためです。対照的に、Admin API 呼び出しではデータベース ルールは考慮されません。ルールを削除すると、クライアント API 呼び出しはサーバー側で機能しますが、データベースがサイバー攻撃にさらされることになります (ローカルの VSCode ターミナルを使い始めて以来、ライブ Firestore データベースを操作し続けています。考えてみてください) .

• 認証から派生した userName や userEmail などのデータ項目を使用するサーバー側のコードは、この情報を取得する別の方法を見つける必要があります。

この投稿では、これらの問題を克服して、サーバー側で安全かつ効率的に実行される高パフォーマンスの Web アプリを作成する方法について説明します。

2. 実際に認証された Svelte サーバー側コード

クライアント呼び出しシグネチャにすでに慣れている場合、Firestore Admin API に切り替える必要があるのは面倒です。しかし、これにはすぐに慣れるので、それほど負担になることはありません。

ただし、ユーザーデータの取得は別問題です。多くのアプリケーションでは、uId などのユーザー プロパティへのアクセスが設計にとって重要です。たとえば、Web アプリでは、ユーザーが自分のデータのみを表示できるようにする必要がある場合があります。残念ながら、これを手配するのは非常に困難です。さあ、始めましょう:

1. まず、クライアント上で、サーバー側のコードがユーザーについて知る必要があるすべての情報を含む「idToken」パッケージを作成する方法を見つける必要があります。 Google は、ユーザーの認証セッション データからこれを構築する getIdToken() メカニズムを提供しています。
2. 次に、このパッケージをサーバーに渡す方法を見つける必要があります。ここで使用されるメカニズムは、サーバーへのクライアント呼び出しに追加される「ヘッダー」にこれを登録します。
3. 次に、Google サーバー上で Firestore Admin API の使用を認証できるようにする Google の「サービス アカウント」を取得する必要があります。これを定義するキーは、プロジェクト ファイルに安全に埋め込む必要があります (Post 3.3 の firebaseConfig.env の議論を思い出してください。
)
4. 最後に、Firestore データベースを使用する必要がある場合は、サーバー側のコードでこれらのサービス アカウント キーを提示する必要があります。

2.1 idToken の取得

<script> の次のコードを見てください。 「ルールに優しい」products-maintenance-rf コードの products-maintenance-sv/page.svelte「server」バージョンのセクション。これは getIdToken() を使用してユーザーの Firebase 認証セッションにアクセスし、idToken<br> を構築します。 </script>

// src/routes/products-maintenance-sv/+page.svelte   
<script>
    import { auth } from "$lib/utilities/firebase-client";
    import { onMount } from "svelte";
    import { goto } from "$app/navigation";

    onMount(async () => {
        if (!auth.currentUser) {
            // Redirect to login if not authenticated, with a redirect parameter
            goto("/login?redirect=/products-maintenance-sv");
            return;
        }

        try {
            // Fetch the ID token directly
            const idToken = await auth.currentUser.getIdToken();
            window.alert("idToken:" + JSON.stringify(idToken));
        } catch (error) {
            window.alert("Error retrieving ID token:", error);
        }
    });
</script>

onMount() の配置については、products-maintenance-rf/page.svelte で前述しましたが、ユーザーが確実にログインしていることを確認するために使用されています。現在は、非同期認証を呼び出して idToken 変数を取得するためにも使用されています。 currentUser.getIdToken()。

新しい src/routes/products-maintenance-sv フォルダーを作成し、その中の新しい page.svelte ファイルに上記のコードを貼り付けます。 次に、http://localhost:5173/products-maintenance-sv の開発サーバーでこれを実行してみます。ログインすると (最後に [Post 3.4](https://ngatelive.nw.r.appspot.com/redirect?post=3.4) で確認された /login/page.svelte のバージョンを使用して、idToken が表示されるはずです。警告メッセージ内。

Firebase ID トークンは JSON Web トークン (JWT) です。 JSON ビットは、「Javascript Object Notation」を使用して文字列としてエンコードされたオブジェクトであることを意味します (これが「JSON」を初めて見た場合は、背景について chatGPT に問い合わせると役立つかもしれません)。 JSON は、JavaScript オブジェクトを文字列として渡す必要がある場合に広く使用されています。 JWT JSON には、ユーザーについて知っておく必要があるすべての情報が含まれています。この情報を抽出する方法については、この投稿の後半で説明します。これは複雑ではありません。

2.2 idToken をサーバーに渡す

この投稿で説明されているメカニズムは、サーバーリクエストに付随する「リクエストヘッダー」内の「Cookie」として「IdToken」を送信します。 「http ヘッダー」は、クライアント ベースの page.svelte ファイルがサーバー ベースの page.server.js ファイルにリクエストを送信するときに Web を通過する情報のパケットです。このようなリクエストは、Firestore ドキュメントを読み書きするたびに送信されます。 「Cookie」は、すべてのリクエスト ヘッダーに追加される文字列です。

この取り決めは複雑ですが、安全であると考えられています。 IT を学ぶ学生の観点からすると、Web デザインの内部についての洞察が得られるため、興味深く、勉強になります。

クライアント側の Javascript プログラムは、JWT を含む 「通常」 Cookie を簡単に設定できますが、セキュリティ上の理由から、これは絶対に行わないでください。これができるなら誰でもできます。一方、サーバー側の page.server.js ファイルは、set-cookie 呼び出しを使用して、クライアント ブラウザーに "http-only" Cookie を設定できます。以下に例を示します:

// src/routes/products-maintenance-sv/+page.svelte   
<script>
    import { auth } from "$lib/utilities/firebase-client";
    import { onMount } from "svelte";
    import { goto } from "$app/navigation";

    onMount(async () => {
        if (!auth.currentUser) {
            // Redirect to login if not authenticated, with a redirect parameter
            goto("/login?redirect=/products-maintenance-sv");
            return;
        }

        try {
            // Fetch the ID token directly
            const idToken = await auth.currentUser.getIdToken();
            window.alert("idToken:" + JSON.stringify(idToken));
        } catch (error) {
            window.alert("Error retrieving ID token:", error);
        }
    });
</script>

上記の httpOnly: true 設定は、Cookie がクライアント側に保持されますが、JavaScript からアクセスできないことを意味します。 このようにして、ここで設定した値が改ざんから確実に保護されるようにすることができます。

ここで問うべき質問は、「idToken がわからないときに、サーバー側 page.server.js ファイルが Set-Cookie コマンドを起動して idToken を設定するにはどうすればよいでしょうか?」ということです。 。

Svelte のserver.js ファイルへようこそ。これは、JavaScript フェッチ コマンドを使用してクライアント側コードから呼び出すことができるサーバー側コードです。このようなサーバー側のコードは「エンドポイント」と呼ばれます。フェッチ コマンドは、Web ベースの「エンドポイント」にリクエストを送信するための Javascript のネイティブ メソッドです。このコマンドを使用すると、リクエストにデータを含めることができるため、これがサーバー上で idToken 値を取得する方法です。以下に例を示します:

    // Set a secure, HTTP-only cookie with the `idToken` token
    const headers = {
      'Set-Cookie': cookie.serialize('idToken', idToken, {
        httpOnly: true
      })
    };

    let response = new Response('Set cookie from server', {
      status: 200,
      headers,
      body: { message: 'Cookie set successfully' }  // Optional message
    });

    return response;

受信者のserver.jsファイルがこれを取得し、そのidTokenを抽出する方法を次に示します。

// client-side +page.svelte code
         const idToken = await user.getIdToken();

            // Send token to the server to set the cookie
            fetch("/api/login", {
                method: "POST",
                headers: { "Content-Type": "application/json" },
                body: JSON.stringify({ idToken }),
            });

あなたはおそらく、「なぜこのコードは何かを「送信」するために「フェッチ」コマンドを使用するのでしょうか?」と考えているでしょう。しかし、あなたはそこにいます。 「Fetch」は、さまざまなタイプの HTTP リクエストを作成するための多用途 API として設計されました。背景を知りたい場合は、chatGPT にチュートリアルを依頼してください。いくつかの例については、を参照してください。

今回の提案は、ログイン ページに、ブラウザーの http 専用 Cookie を設定する server.js 呼び出しを実行させることです。 Cookie が設定されると、有効期限が切れるまでブラウザが行うすべての HTTP 呼び出しに自動的に追加されます。

これを実行するには、ログイン ページの次の login-and-set-cookie/page.svelte バージョンと、それに付随する api/set-cookie/server.js エンド ポイント用に新しいフォルダーとファイルを作成します。

// server-side +server.js code
export async function POST({ request }) {
  const { idToken } = await request.json();
}

api/set-cookie/server.js を使用するには、まず npm「cookie」ライブラリをインストールする必要があることに注意してください。このライブラリは、HTTP 応答ヘッダーに含めるために適切にフォーマットされた Cookie を作成するのに役立ちます。

// src/routes/login-and-set-cookie/+page.svelte
<script>
    import { onMount } from "svelte";
    import { auth, app } from "$lib/utilities/firebase-client";
    import { goto } from "$app/navigation"; // SvelteKit's navigation for redirection
    import { signInWithEmailAndPassword } from "firebase/auth";

    let redirect;
    let email = "";
    let password = "";

    onMount(() => {
        // Parse the redirectTo parameter from the current URL
        const urlParams = new URLSearchParams(window.location.search);
        redirect = urlParams.get("redirect") || "/";
    });

    // this code will run after a successful login.
    auth.onAuthStateChanged(async (user) => {
        if (user) {
            const idToken = await user.getIdToken();

            console.log("In login_awith-cookie : idToken: ", idToken);

            // Send token to the server to set the cookie
            fetch("/api/set-cookie", {
                method: "POST",
                headers: { "Content-Type": "application/json" },
                body: JSON.stringify({ idToken }),
            });

            window.alert("In with-cookie : cookie set");
            goto(redirect);
        }
    });

    async function loginWithMail() {
        try {
            const result = await signInWithEmailAndPassword(
                auth,
                email,
                password,
            );
        } catch (error) {
            window.alert("login with Mail failed" + error);
        }
    }
</script>

<div>





<pre class="brush:php;toolbar:false">// src/routes/api/set-cookie/+server.js
import admin from 'firebase-admin';
import cookie from 'cookie';

export async function POST({ request }) {
  const { idToken } = await request.json();

  try {
    // Verify the token with Firebase Admin SDK
    const decodedToken = await admin.auth().verifyIdToken(idToken);

    // Use the cookie.serialize method to create a 'Set-Cookie' header for inclusion in the POST
    // response. This will instruct the browser to create a cookie called 'idToken' with the value of idToken
    // that will be incorporated in all subsequent browser communication requests to pages on this domain.

    const headers = {
      'Set-Cookie': cookie.serialize('idToken', idToken, {
        httpOnly: true,          // Ensures the cookie is only accessible by the web server
        secure: true,            // Ensures the cookie is only sent over HTTPS
        sameSite: 'None',        // Allows the cookie to be sent in cross-site requests
        maxAge: 60 * 60,         // 1 hour (same as Firebase ID token expiry)
        path: '/'                // Ensures the cookie is sent with every request, regardless of the path.
      })
    };

    let response = new Response('Set cookie from login', {
      status: 200,
      headers,
      body: { message: 'Cookie set successfully' }  // Optional message
    });

    console.log("Cookie set")

    return response;

  } catch (err) {
    console.error("Error in login server function: ", err);

    let response = new Response('Set cookie from login', {
      status: 401,
      body: { message: 'Unauthorized' }  // Optional message
    });

    return response;
  }
};

「ログアウトして Cookie を削除する」ログアウト ページは必要ありません。新しい Cookie を設定すると、同じ名前の古いバージョンが上書きされます。

2.3 プロジェクトでのサービス アカウントの設定

プロジェクトのサービス アカウントは、安全なキーと「所有者」情報 (プロジェクトの projectId など) が詰め込まれたオブジェクトです。 「page.server.js」ファイルが実行されると、ファイル内に埋め込まれたサービス アカウントのコピーが Google に提示されます。 2 つが一致する場合、サーバー ファイルは認証されます。

手順は次のとおりです:

1. クラウド上でプロジェクトのサービス アカウントを作成してダウンロードする、
2. これをプロジェクトに埋め込み、
3. 比較の実行に必要な「firebase-admin」ライブラリをプロジェクトにインストールします

2.3.1 サービスアカウントの作成

1. Google Cloud コンソールに移動します。
2. IAM と管理 > に移動します。 サービス アカウント をクリックし、これが svelte-dev プロジェクトを指していることを確認します (左上のプルダウン メニューを使用します)。 IAM (Identity and Access Management) 画面には、プロジェクトの Google Cloud リソースに対して誰が何を実行できるかを制御するすべての Cloud 権限が一覧表示されます。これはそれ自体で「投稿」に値しますが、今はその時ではありません
3. IAM ページからサービス アカウント ページに切り替えるには、画面左側のツールバーにマウスを置き、[サービス アカウント] というラベルの付いたツールバーをクリックします。デフォルトのアカウントがすでに作成されていることがわかります。
4. ページの上部にある [サービス アカウントの作成] ボタンをクリックし、「svelte-dev」などの一意のサービス アカウント名 (またはお好みの名前 - 6 から 6 までの範囲にする必要があります) で新しいサービス アカウントを作成します。長さは 30 文字で、小文字の英数字とダッシュのみが表示されます) クラウド全体で一意であることが保証されたこのバージョンは、「サービス アカウント ID」フィールドに反映されることをお勧めします。それが提供するものは何でも。

5. [作成して続行] ボタンをクリックし、[このサービス アカウントにプロジェクトへのアクセスを許可する] セクションに進みます。まず、フィールド上のプルダウン メニューを開きます。パネルが 2 つあるため、少し複雑です。左側のパネル (スライダー バーあり) では、製品またはサービスを選択できます。右側には、そのサービスで使用できるロールがリストされています。左側のパネルで「Firebase」サービスを選択し、右側のパネルで「Admin SDK Administrator Service Agent」ロールを選択します。 [続行] をクリックし、[完了] をクリックしてサービス アカウント画面に戻ります

6. 最後に、作成したばかりの「Firebase Admin SDK Service Agent」キーのエントリの右側にある「3 点」メニューをクリックし、「キーの管理」を選択します。 「キーの追加」をクリックします。新しいキーを作成 > JSON >新しいファイルを作成し、「ダウンロード」フォルダーに新しいファイルが表示されたことを確認します。これが「サービス アカウント キー」です。あとはこれをプロジェクトに埋め込むだけです。

2.3.2 ダウンロードしたサービス アカウントをプロジェクトに埋め込む

1. サービス アカウント キーの安全な場所を提供するために、プロジェクトのルートに /secrets フォルダーを作成します。ダウンロードしたサービス アカウント ファイルを /secrets/serviceAccount.json ファイルに移動し、「/secrets」フォルダーとその編集履歴を「.gitignore」ファイルに追加します。

// src/routes/products-maintenance-sv/+page.svelte   
<script>
    import { auth } from "$lib/utilities/firebase-client";
    import { onMount } from "svelte";
    import { goto } from "$app/navigation";

    onMount(async () => {
        if (!auth.currentUser) {
            // Redirect to login if not authenticated, with a redirect parameter
            goto("/login?redirect=/products-maintenance-sv");
            return;
        }

        try {
            // Fetch the ID token directly
            const idToken = await auth.currentUser.getIdToken();
            window.alert("idToken:" + JSON.stringify(idToken));
        } catch (error) {
            window.alert("Error retrieving ID token:", error);
        }
    });
</script>

これは、Git リポジトリ内のファイルが不用意に公開されるのを防ぐための、ポスト 3.3 で前述した保護メカニズムのもう 1 つのインスタンスです。 Windows ユーザーの場合、さらに安全なアプローチは、Windows GOOGLE_APPLICATION_CREDENTIAL 環境変数を作成して主要な参照を提供することです。

2.3.3 プロジェクトへの「firebase-admin」ライブラリのインストール

「サーバー ログオン」手順を実行するには、page.server.js コードが Firebase 管理 API にアクセスする必要があります。これは、プロジェクトに「firebase-admin」をインストールすることで取得できます:

    // Set a secure, HTTP-only cookie with the `idToken` token
    const headers = {
      'Set-Cookie': cookie.serialize('idToken', idToken, {
        httpOnly: true
      })
    };

    let response = new Response('Set cookie from server', {
      status: 200,
      headers,
      body: { message: 'Cookie set successfully' }  // Optional message
    });

    return response;

次のコマンドを使用して、コード内に管理者参照を作成できるようになりました。

// client-side +page.svelte code
         const idToken = await user.getIdToken();

            // Send token to the server to set the cookie
            fetch("/api/login", {
                method: "POST",
                headers: { "Content-Type": "application/json" },
                body: JSON.stringify({ idToken }),
            });

このインポートの構文は、これまで使用してきたものとは異なることに注意してください。「admin」ビットの周りに中括弧がありません。これまで使用してきた他のライブラリでは名前付きコンポーネントをインポートできましたが、このバージョンではデフォルト管理エクスポートから全体をインポートする必要があります。これにより、親管理オブジェクトの admin.auth()、admin.firestore() などの プロパティ としてコンポーネントが提供されます。このライブラリの設計者は、この状況ではこれがより現実的な配置であるとの見解をとりました。

デフォルトのインポートを使用する場合、インポートされた親オブジェクトに好きな名前を付けることができます (たとえば、admin の代わりに myFirebaseAdmin と呼ぶこともできます)。この配置を、前に作成した lib/utilities/firebase-config ファイルの名前付きエクスポート アプローチと比較してください

2.4 page.server.js ファイルでのサービス アカウントと idToken の使用

ここで、最終的に Firestore Admin API を使用して Firestore データベース サーバー側にアクセスする方法の核心に入ります。

まず、サービス アカウント キーを使用してアプリを「初期化」し、管理 API の使用に必要な adminDb オブジェクトを作成する権限を取得します (クライアント API に db が必要な場合と同様)。次に、Cookie から idToken を取得し、そこから Firestore 呼び出しで必要になる可能性のあるユーザー コンテンツを抽出する必要があります。この時点で、ようやく Firestore Admin API を使用してこれらの呼び出しを自由にコーディングできるようになります。

以下にリストされているコードを、src/routes/products-maintenance-sv フォルダー内の新しい page.server.js ファイルにコピーします。これは、Post 3.3 で最初に見られた製品メンテナンス コードの「サーバー バージョン」です。そこでは、Firestore クライアント API を使用しようとするサーバー側のコードが、アドレス指定しているコレクションが Firestore データベース ルールの対象となる場合にどのように失敗するかを示すために使用されていました。この新しいバージョンには次の利点があります:

• Firestore Admin API コマンドの使用を可能にし、データベース ルールを無視できるようにするサービス アカウント キー
• 認証されたユーザーの詳細を取得できるようにする idToken Cookie

// src/routes/products-maintenance-sv/+page.svelte   
<script>
    import { auth } from "$lib/utilities/firebase-client";
    import { onMount } from "svelte";
    import { goto } from "$app/navigation";

    onMount(async () => {
        if (!auth.currentUser) {
            // Redirect to login if not authenticated, with a redirect parameter
            goto("/login?redirect=/products-maintenance-sv");
            return;
        }

        try {
            // Fetch the ID token directly
            const idToken = await auth.currentUser.getIdToken();
            window.alert("idToken:" + JSON.stringify(idToken));
        } catch (error) {
            window.alert("Error retrieving ID token:", error);
        }
    });
</script>

コードが userEmail フィールドを構築する興味深い方法に注目してください

    // Set a secure, HTTP-only cookie with the `idToken` token
    const headers = {
      'Set-Cookie': cookie.serialize('idToken', idToken, {
        httpOnly: true
      })
    };

    let response = new Response('Set cookie from server', {
      status: 200,
      headers,
      body: { message: 'Cookie set successfully' }  // Optional message
    });

    return response;

verifyIdToken メソッド名を見ると、これがユーザーを再度認証しようとしているのではないかと疑問に思うかもしれません。心配しないでください。そんなことはありません。トークンに埋め込まれた「署名」のセキュリティ チェックを実行して、トークンが改ざんされておらず、有効期限が切れていないことを確認しているだけです。

verifyIdToken によって作成される decodedToken は、認証されたユーザーの email や userName プロパティなどを含む単純なオブジェクトです。後続の Firestore コードではこれらのいずれも使用していませんが、どのように使用するかは簡単に想像できると思います。

管理 API 呼び出しをコーディングするときは、「定型的な」アプローチを再度使用することをお勧めします。必要に応じて、chatGPT を使用して、Post 10.1 に記載されているクライアント コードを変換します。

次に、前に作成した src/routes/products-maintenance-sv/page.svelte ファイルの内容を、以下に示すコードに置き換えます。これにより、products-maintenance-sv/page.server.js ファイルにクライアント フロントエンドが提供されます:

// src/routes/products-maintenance-sv/page.svelte

    「svelte」から { onMount } をインポートします。
    import { auth } から "$lib/utilities/firebase-client";
    import { goto } from "$app/navigation";
    import { productNumberIsNumeric } から "$lib/utilities/productNumberIsNumeric";

    // onMount 内の onAuthStateChanged コールバック内で認証状態の変更をチェックします。これはどうやら
    // 奇妙なことですが、サーバー側のアクティビティを完了して auth.currentUser を安定した状態にする唯一の方法のようです
    // 州。これはクライアント側の「ルールフレンドリー」バージョンでは問題ではありませんでしたが、すぐに問題になりました
    // action() を含む page.server.js ファイルとして追加されました。

    onMount(async () => {
        auth.onAuthStateChanged(async (ユーザー) => {
            if (!auth.currentUser) {
                // 認証されていない場合はログインにリダイレクトされます。パラメータはログインにここに戻る方法を指示します
                goto("/login-and-set-cookie?redirect=/products-maintenance-sv");
            }
        });
    });

    製品番号をみましょう;
    製品の詳細をみましょう。

    製品番号クラス = "製品番号";
    submitButtonClass = "submitButton";

    let フォームをエクスポートします。
スクリプト>


    
        製品番号
        



<p>これを開発サーバーで実行するには、まず http://localhost:5173/logout でログアウトします。次に、http://localhost:5173/products-maintenance-sv を実行します。これにより、ログインとクッキーの設定ページにログインするよう促されます。 </p>

<p>ログインに成功すると、新しい製品の作成を促す見慣れたフォームが表示されます。 </p>

<p>この時点で、login-and-set-cookie ページは、ブラウザーに idToken cookie を安全に設定しているはずです。データを入力してフォームを送信すると、制御は products-maintenance-sv/page.server.js のサーバー側コードに渡されます。これは、プロジェクトに組み込まれたサービス コードを提示することで自身を認証し、ヘッダーから idToken を取得し、Sveltekit リクエストのフォーム オブジェクトからその入力データを取得します。このコードは、idToken で使用可能なユーザー データを使用して何も役に立ちませんが、userEmail の値を表示するログ メッセージが VSCode ターミナルに表示されます。最後に、Firestore 管理コードにより、新しい製品が製品データベース コレクションに追加されます。</p>

<p>古い http://localhost:5173/products-display-rf ページを実行すると、アップデートが正常に適用されたことを確認できます。</p>

<p>フォームが送信されると、確認メッセージが表示され、入力フィールドがクリアされることに注意してください。 「フォームの更新」は、フォーム送信後の Javascript のデフォルトのアクションです。 </p><p>製品コレクションに Firestore 認証ルールが設定されている Firestore <strong>クライアント</strong> API コード サーバー側がまだ実行されているときに、http://localhost:5173/products-display-rf ページがどのように動作するのか疑問に思われるかもしれません。違いは、これらのルールが書き込みにのみ適用されることです。 products-display-rfcode はドキュメントを読み取っているだけです。 </p>

<p>実際には、混乱を避けることを懸念して products-display-sv の products-display-sv バージョンを作成することにした場合は、全体を通して Firestore <strong>Admin</strong> API 呼び出しを使用することになると思います。 。ただし、その場合は、initializeApp.</p> にサービス アカウントの資格情報を提示することから始める必要があることに注意してください。

<h3>
  
  
  3. まとめ
</h3>

<p>これは長い投稿であり、Javascript の限界まで負荷がかかってしまいます。この時点でまだ私と一緒にいるなら、よくやった。本当に、よくやった。並外れた粘り強さを見せてくれたね！ </p>

<p>前の投稿で紹介した「クライアント側」のテクニックは楽しく使えますが、サーバー側の取り決めによるセキュリティと速度の利点を理解していただければ幸いです。経験を積むと、サーバー側のコード開発もクライアント側の作業と同じくらい簡単かつ自然になるでしょう。</p>

<p>しかし、やるべきことがまだ残っています。これで、開発サーバーで問題なく動作する多くのページを含む Web アプリを開発できましたが、これらはまだ Web 上には表示されていません。</p>

<p>次の投稿では、Web アプリを Google AppEngine に「構築」してデプロイし、熱心な一般公開する方法について説明します。これは大きな瞬間になるでしょう! </p>

<p>読み続けて、何をする必要があるのか​​を見つけるエネルギーがまだ残っていることを願っています。それほど難しいことではありません。</p>

<h3>
  
  
  追記: 問題が発生した場合 - インスペクターでヘッダーを表示する
</h3>

<p>実際、このセクションで問題が発生する可能性のあるものの数はおそらく無限に近いでしょう。あまりパニックにならず、プロジェクトのファイル構造を注意深く観察してください。正しいコードを間違ったファイルに入れたり、正しいファイルを間違ったフォルダーに入れたりするのは非常に簡単です。さらに、ターミナル セッションを強制終了して再起動することで、定期的に「環境を整える」と役立つ場合があります。少なくとも、これにより、一連のエラーの最初の原因を探すときに白紙の状態になります。</p>

<p>しかし、ここではヘッダーと Cookie を操作しているので、ブラウザのインス​​ペクター ツールを使用すると、これらのことを視覚的に把握できることを知っておくと役に立つでしょう。インスペクターは、ページのリクエスト ヘッダーに埋め込まれた Cookie を<strong>表示</strong>できます。</p><p>この機能の動作を確認するには、まず https://myLiveUrl/logout (myLiveUrl はデプロイされた Web アプリケーションのアドレス) でライブ システムからログアウトしていることを確認します。次に、https://https://myLiveUrl/products-maintenance-sv で products-maintenance=sv ページを実行します。ログインし、「新しい製品の入力」フォームでインスペクターを開き、「ネットワーク」タブをクリックします。これにより、ページによって行われたネットワーク リクエストのリストが表示されます。</p>

<p>次に、Web アプリを使用して新しい製品を挿入し、「リクエスト」リストがどのように更新されるかを確認します。これらは、単純な更新を実行するために必要なネットワーク リクエストです。驚くほど長いリストです。このリストの先頭までスクロールして戻ると、products-maintenance-sv ページのエントリが見つかるはずです。これをクリックすると、リクエスト リストの右側のパネルに、トランザクションのレスポンスとリクエスト ヘッダーの両方の詳細が表示されます。以下のスクリーンショットは、リクエスト ヘッダー内に埋め込まれた Cookie を示しています。</p>

<p><img src="/static/imghwm/default1.png" data-src="https://img.php.cn/upload/article/000/000/000/173301818045981.jpg?x-oss-process=image/resize,p_40" class="lazy" alt="NgSysV.A Serious Svelte InfoSys: A Client-Server Version"></p>