035.2 レッスン 1

Expressの基本的な機能である、リクエストの受信と処理を実演するために、サーバにいくつかの情報をリクエストするアプリケーションをシミュレートしてみましょう。具体的には、例のサーバが下記の処理を行います。

まず最初に、サーバとして動作するJavaScriptファイルを作成します。 npm を使って、 myserver というディレクトリを作成し、その中にJavaScriptのファイルを置きます。

エントリポイントには、任意のファイル名を使用できます。ここでは、デフォルトのファイル名である index.js を使用します。以下のリストは、サーバのエントリーポイントとして使用する基本的な index.js ファイルを示しています。

このスクリプトの最初の行では、サーバの設定に必要ないくつかの重要な定数が定義されています。最初の2つ、 express と app は、組み込まれている express モジュールと、アプリケーションを実行するこのモジュールのインスタンスに対応しています。ここでは、サーバが実行するアクションを app オブジェクトに追加します。

他の2つの定数、 host と port は、サーバに関連するホストと通信ポートを定義します。

公開されているホストがある場合は、 host の値として myserver の代わりにその名前を使います。ホスト名を指定しない場合、Expressはアプリケーションが動作するコンピュータである localhost をデフォルトとします。この場合、外部のクライアントはプログラムにアクセスすることができません。これは、テストのためには良いかもしれませんが、本番環境ではほとんど意味がありません。

ポートが指定されていないと、サーバが起動しません。

このスクリプトでは、 app オブジェクトに2つのプロシージャのみをアタッチしています。HTTPの GET でクライアントからのリクエストに答える app.get() アクションと、 app.listen() コールで、サーバを起動してホストとポートを割り当てる必要があります。

サーバを起動するには、 node コマンドを実行し、引数としてスクリプト名を指定します。

Server ready at http://myserver:8080 というメッセージが表示されると、サーバはHTTPクライアントからのリクエストを受信する準備ができたことになります。リクエストは、サーバが動作しているコンピュータ上のブラウザからでも、サーバにアクセス可能な他のマシンからでも可能です。

ここで紹介するすべてのトランザクションの詳細は、開発者コンソール用のウィンドウを開くとブラウザに表示されます。また、HTTP通信には curl コマンドを使用することができ、より簡単に接続の詳細を検査することができます。シェルのコマンドラインに慣れていない場合は、HTMLフォームを作成してサーバにリクエストを送信することができます。

次の例では、コマンドラインで curl コマンドを使用して、新しくデプロイされたサーバに HTTPリクエストを行う方法を示しています。

curl コマンドの -v オプションは、すべてのリクエストヘッダーとレスポンスヘッダー、およびその他のデバッグ情報を表示します。 > で始まる行は、クライアントが送信したリクエストヘッダーを示し、 < で始まる行は、サーバが送信したレスポンスヘッダーを示します。また、 * で始まる行は、 curl 自身が生成する情報です。レスポンスの内容は最後にのみ表示され、この場合は Request received の行になります。

サービスのURLは、この場合、サーバのホスト名とポート ( http://myserver:8080 ) を含んでおり、 curl コマンドの引数として与えられました。ディレクトリやファイル名が指定されていないため、これらのデフォルトはルートディレクトリ / になります。スラッシュは > GET / HTTP/1.1 行のリクエストファイルとして現れ、出力ではホスト名とポートが続きます。

curl コマンドは、HTTP接続ヘッダーを表示するだけでなく、異なるHTTPメソッドや異なるフォーマットでデータをサーバに送信することができるので、アプリケーションの開発を支援します。この柔軟性により、問題のデバッグやサーバへの新機能の実装が容易になります。

クライアントがサーバにリクエストできる内容は、 index.js ファイルで定義された ルート に依存します。ルートは、HTTPメソッドを指定し、クライアントがリクエストできる パス （正確にはURI）を定義します。

今のところ、サーバには1つのルートしか設定されていません。

単にプレーンテキストのメッセージをクライアントに返すだけの非常にシンプルなルートですが、ほとんどのルートを構成するのに使われる最も重要なコンポーネントを確認するには十分です。

テストサーバの機能を拡張するために、HTTPの POST メソッド用のルートを定義する方法を見てみましょう。このメソッドは、クライアントが、リクエストヘッダーに含まれている以上のデータをサーバに送信する必要がある場合に使用します。 curl コマンドの --data オプションは、自動的に POST メソッドを起動し、 POST を介してサーバに送信されるコンテンツを含んでいます。以下の出力の POST / HTTP/1.1 の行は、 POST メソッドが使用されたことを示しています。しかし、サーバでは GET メソッドしか定義されていないため、 curl を使用して POST でリクエストを送信するとエラーが発生します。

前述の例では、 --data message="This is the POST request body" というパラメータを指定して curl を実行すると、message という名前のテキストフィールドに This is the POST request body を入力してフォームを送信することに相当します。

サーバは / パスに対して1つのルートしか設定されておらず、そのルートは HTTP GET メソッドにしか応答しないため、応答ヘッダーには　HTTP/1.1 404 Not Found という行が含まれています。また、Expressでは自動的に短いHTMLレスポンスが生成され、警告として Cannot POST が表示されました。

curl を使って POST リクエストを生成する方法を見てきましたが、今度はそのリクエストをうまく処理できるExpressプログラムを書いてみましょう。

まず、リクエストヘッダーの Content-Type フィールドには、クライアントから送信されたデータが application/x-www-form-urlencoded 形式であることが示されています。Expressはこの形式をデフォルトでは認識しないので、 express.urlencoded モジュールを使用する必要があります。このモジュールをインクルードすると、ハンドラ関数のパラメータとして渡される req オブジェクトに req.body.message プロパティが設定され、これがクライアントから送信された message フィールドに対応します。このモジュールは app.use でロードされます。これはルートの宣言の前に置く必要があります。

これができれば、既存のルートで app.get を app.post に変更するだけで、 POST 経由のリクエストに対応し、リクエストボディを復元することができます。

ExpressはリクエストヘッダーでHTTPメソッドを識別し、適切なルートを使用するため、ルートを置き換えるのではなく、単純にこの新しいルートを追加することも可能です。このサーバには複数の機能を追加したいので、 /echo や /ip のように、それぞれを独自のパスで区切っておくと便利です。

これまでの例で見てきたように、 res パラメータはクライアントにレスポンスを返す役割を担っています。さらに、 res オブジェクトは、レスポンスの他の側面を変更することができます。お気づきかもしれませんが、これまでに実装したレスポンスは単なる簡潔なプレーンテキストのメッセージですが、レスポンスの Content-Type ヘッダーには text/html; charset=utf-8 が使用されています。これはプレーンテキストのレスポンスを受け付けることを妨げるものではありませんが、レスポンスヘッダーのこのフィールドを res.type('text/plain') という設定で text/plain に再定義することで、より正しくなります。

他のタイプのレスポンス調整には、サーバが以前にリクエストを行ったクライアントを識別できるようにする クッキー の使用が含まれます。クッキーは、リクエストを特定のユーザーに関連付けるプライベートセッションの作成など、高度な機能を実現するために重要ですが、ここでは、以前にサーバにアクセスしたことのあるクライアントを特定するためにクッキーを使用する簡単な例を見てみましょう。

Expressのモジュール化されたデザインを考慮すると、クッキー管理機能は、スクリプトで使用する前に、 npm コマンドでインストールする必要があります。

インストール後、クッキーの管理をサーバスクリプトに含める必要があります。以下の定義をファイルの先頭付近に記述してください。`

クッキーの使い方を説明するために、スクリプト内にすでに存在する / のルートパスを使って、ルートのハンドラ関数を修正してみましょう。 req オブジェクトは req.cookies プロパティを持ち、ここにリクエストヘッダーで送信されたクッキーが保存されます。一方、 res オブジェクトは res.cookie() メソッドを持ち、クライアントに送信する新しいクッキーを作成します。以下の例のハンドラ関数は、 known という名前のクッキーがリクエストに存在するかどうかをチェックします。そのようなクッキーが存在しない場合、サーバは初めての訪問者であると仮定して、 res.cookie('known', '1') の呼び出しによりその名前のクッキーを送ります。このクッキーには何らかのコンテンツがあるはずなので、任意に値 1 を割り当てますが、サーバはその値を参照しません。このアプリケーションでは、クッキーが存在するだけで、クライアントが以前にこのルートをリクエストしたことがあると仮定しています。

デフォルトでは、 curl はトランザクションでクッキーを使用しません。しかし、保存したり（ -c cookies.txt ）、保存したクッキーを送信したり（ -b cookies.txt ）するオプションがあります。

このコマンドは、サーバにクッキーが実装されてから初めてのアクセスだったので、クライアントはリクエストに含めるクッキーを持っていませんでした。予想通り、サーバはリクエストに含まれるクッキーを識別できなかったため、出力の Set-Cookie: known=1; Path=/ 行で示されるように、レスポンス・ヘッダーにクッキーを含めました。 curl でクッキーを有効にしているので、新しいリクエストはクッキー known=1 をリクエストヘッダーに含め、サーバがクッキーの存在を識別できるようにします。

開発者は、リクエストを行うクライアントを識別するためにクッキーを使用する場合、潜在的な脆弱性に注意する必要があります。攻撃者は、 クロスサイトスクリプティング （XSS）や クロスサイトリクエストフォージェリ （CSRF）などの手法を用いて、クライアントからクッキーを盗み出し、それによってクライアントになりすましてサーバにリクエストを行うことができます。一般的にこの種の攻撃は、検証されていないコメント欄や綿密に作成されたURLを利用して、悪意のあるJavaScriptコードをページに挿入します。本物のクライアントがこのコードを実行すると、有効なCookieをコピーして保存したり、別の宛先に転送したりすることができます。

そのため、特にプロフェッショナルなアプリケーションでは、 ミドルウェア として知られる、より専門的なExpressの機能をインストールして使用することが重要です。 express-session または cookie-session モジュールは、セッションとクッキーの管理をより完全かつ安全に制御します。これらのコンポーネントは、クッキーが元の発行者から転用されるのを防ぐための特別な制御を可能にします。