以前のブログ記事で、4D RESTサーバを始める方法を紹介しました。Postmanを使った様々なCRUDオペレーションを紹介し、RESTの完全なドキュメントを紹介しました。今回のブログでは、4Dでセッションがどのように機能するかを説明します。この理解によって、4D RESTサーバを使用してセッションベースの認証システムを構築することができるようになります。
4Dレストセッション
もしあなたが認証システムの構築に興味があるなら、セッションベースのシステムはあなたが探しているものです!
4DREST サーバーへの接続は、セッションベースです。これは、クライアントから最初のリクエストが送信されたときに、4Dサーバーがセッションを作成し、セッションクッキーを送り返すことを意味します（WASID4D）。それ以降のすべてのリクエストについて、クライアントはリクエストのヘッダーにこのセッションクッキーを返さなければなりません。これは、サーバー側でセッションが永続化されず、クライアント側で保存されるトークンベースの認証とは逆になります。
RESTサーバーの設定
セッションがどのように処理されるかについてよく理解できたので、次に進みましょう。始める前に、4D RESTサーバーを起動し、設定する必要があります。先に進む前に、この ブログ記事またはドキュメントセンターを参照してください。
RESTの認証方法について
The On REST Authenticationデータベースメソッドは、4D上でRESTセッションを開く方法を制御するカスタム方法を提供します。RESTセッションを開くリクエストを受信すると、接続識別子（ユーザー名とパスワードなど）がリクエストのヘッダーに提供されます。On REST Authentication データベースメソッドが呼び出され、これらの識別子を評価し、True（セッションのオープンが受け入れられた）またはFalse（セッションのオープンが拒否された）を返すことができるようにします。
注：このデータベースメソッドは、データベースへの独自のアクセス制御をコード化するために使用されますが、4Dユーザーグループを使用してアクセスを制限することもできます。データベースを公開する際に、データベース設定 > Web > RESTリソースタブで、アクセスを許可するグループを選択します。このブログポストで記憶を呼び覚ましてください。
セッションを開く
セッションのオープンを説明するために、ログインとパスワードが設定された投稿フォームを想像してみましょう。POSTリクエストのヘッダで認証情報を送信するために、Postmanを使用することにします。4DアプリケーションでRESTを通してセッションを開くには、 $directory/loginを使用します。
4Dに戻って何が起こっているのか見てみましょう。
ご覧の通り、データベースメソッドは4つのパラメータを受け取ります。
- 1がユーザー名。
- 2はパスワードです。
- 3はパスワードがハッシュ化されていればTrueを、ハッシュ化されていなければFalseを返します。
- 4には呼び出し元のIPアドレスが格納されています。
注：現実の世界では、パスワードはハッシュ化されるべきであり、平文で送信してはならない。ハッシュ化されたパスワードを送信するには、password-4Dの代わりにhashed-password-4D パラメータを使用することができます。この コード例では、どのように処理するのかを説明しています。
リクエストを受信すると、サーバーはセッションを開き、セッション・クッキーをクライアントに送り返します（WASID4D）。
セッションが作成されたので、その後のHTTPリクエストでそのIDをどのように渡せばいいのでしょうか？
待ってください……そもそも、なぜこんなことをしなければならないのでしょうか？
セッションの管理
HTTP は「ステートレス」プロトコルです。クライアントが Web ページに接続するたびに、Web サーバーへの個別の接続が開かれます。サーバーは、以前のクライアントからのリクエストの記録を保持しません。何千ものクライアントがサーバーに接続したと仮定して、どのセッションが自分のものかをどうやって知ることができるでしょうか？そこで登場するのが、セッションIDです。このセッションIDの交換によって、状態が維持されるのです。これはどういうことでしょうか。つまり、同じセッションを再利用するためには、それ以降のすべてのRESTリクエストに、リクエストの「Cookie」ヘッダーにセッションIDを 含める必要がある、ということです。そうしないと、新しいセッションが開かれます（そして新しいセッションは新しいライセンスを意味します）。
例
セッションを処理する方法は、実際にはHTTPクライアントに依存します。例えば、 HTTP Request コマンドでリクエストを処理するような状況だとします。
ヘッダにセッションIDを含めるには、まずそれを見つける必要があります。簡単です!セッションが WASID4D キーを持っていることは分かっているので、Find in array コマンドを使ってヘッダの値からこのキーを探せばいいだけです。
Find in array($headerValues; "wasid4d@")
見つかったら、それを抽出しよう。
$start:=Position("WASID4D";$cookie)
$end :=Position(";";$cookie)
$uuid :=Substring($cookie;$start;$end-$start) $uuid は、以降のすべてのリクエストで送られるセッションIDをホストしています。完全な例は、こちらをご覧ください。
セッションのタイムアウトを制御する
デフォルトでは、セッションの非アクティブ時のタイムアウトは60分で、これより短くすることはできません。しかし、$directory/loginメソッドのPOSTヘッダで渡すことができる“session-4D-length“パラメータの値で、タイムアウト時間を長くすることができます。
もう1つ
4Dサーバーは、以前のクエリーやオーダーコマンドに基づくエンティティの選択をセッションに保存しています。そのため、次の「範囲」（またはチャンク）のデータが必要になったときに、再度クエリーやオーダーをする必要がなく、単に次のデータセットを送信するだけでよいのです。このメカニズムにより、トランザクションや悲観的ロックなどの利用が可能になります。
次は？
4D v18でRESTサーバーは大幅に強化され、将来的にはさらに多くの機能が追加される予定です。それまでの間、私たちは例や実用的な使用例を提供し続けます。4Dフォーラムでの議論に気軽に参加してください。