4D Japan
テクニカルサポートブログ-
Write Proドキュメントの要素リストを取得する
WP Get elementsにWrite Proドキュメントを渡した場合，要素のid順にソートされたコレクションが返されます。本文に出現する順序ではない点に留意してください。これは仕様です。本文に出現する順序で要素を取得したいのであれば，Write Proドキュメント本文のレンジオブジェクトを渡してください。$Paragraphs:=WP Get elements(WParea;wk type paragraph) //ID順 $Paragraphs:=WP Get elements(WP Get body(WParea);wk type paragraph) //出現順
-
4D RESTセッションの理解を深める
前回のブログで、4D RESTサーバーを開始する方法をご覧いただきました。Postmanを使って異なるCRUD操作を経験し、完全なるRESTドキュメントへと導きました。今回のブログでは、4Dの中でセッションがどのように働くのかを説明します。これを理解することで、4D RESTサーバーを使ったセッションベースの承認システムの構築ができることを確信しています。
4D RESTセッション
認証システムの構築を目指すなら、あなたの探しているものはセッションベースのシステムです！
4DRESTサーバーへの接続は、セッションベースです。これは、4Dサーバーがセッションを作るのは、最初のリクエストがクライアント(WASID4D)によって送られ、セッションクッキーが返送された時であるということです。全てのサブスクエント・リクエストに対して、クライアントはリクエストへのヘッダー中のセッションクッキーを返さなければなりません。これは、サーバー側にはセッションが残っていないけれどクライアント上に保存されている、トークンベース認証とは反対になります。
RESTサーバーを構築
では、セッションの扱い方をよく理解できたところで、さらに前進します。始める前に、4D RESTサーバーを開始しえて、構成します。さらに始める前に、このブログあるいはドキュメントセンターを参照してください。
ON REST AUTHENTICATIONメソッド
データベースメソッドのOn REST Authenticationによって、4D上でRESTセッションの開き方のコントロールをカスタマイズする方法が使えるようになります。RESTセッションを開くリクエストを受けた時、接続確認（例：ユーザー名とパスワード）がリクエストのヘッダーに提供されます。On REST Authenticationデータベースメソッドが呼ばれるので、これらの認証を評価でき、True（セッションの開始を承認）あるいはFalse（セッションの開始を拒否）を返します。
注記：このデータベースメソッドがデータベースへの独自のアクセスコントロールのコーディングに使われている間、アクセスは4Dユーザー・グループを使って制限することも可能です。データベースを表示している際に、データベース設定 > Web > RESTリソース・タブにアクセスを許可されたグループを選択します。このブログで記憶を取り戻してください。
セッションを開く
セッションの開始を図解するには、ログインとパスワードを伴うサブミッション・フォームを想像しましょう。POST リクエストのヘッダー内の認証情報を送るのにPostmanを使っています。RESTを通じて4Dアプリケーション内のセッションを開くために、$directory/login:を使います。
4Dに戻ってどうなるか見てみましょう。
ご覧の通り、データベースメソッドはパラメータを受け取ります。
- ユーザー名には$1
- パスワードには$2
- $3は、パスワードがハッシュされたらTrueを、されなかったらFalseを返します。
- $4はコーラーのIPアドレスを保持します。
注記：現実には、パスワードはハッシュされて、暗号化されていない状態で送られることはありません。ハッシュされたパスワードを送るには、password-4Dの代わりにhashed-password-4Dパラメータを使うことができます。このコードサンプルでどのように処理するかチェックしてください。
一度リクエストが受け取られると、サーバーはセッションを開き、セッションクッキーをクライアント (WASID4D)へ送り返します：
これでセッションが作成されました。結果として生じるHTTPリクエストへそのIDを返すにはどうしたらよいでしょう。
待ってください…なぜ、最初にこれをやる必要があるのでしょう。
セッション管理
HTTPは「ステートレス」プロトコルです…クライアントがWebページに接続するたびに、Webサーバーへ区別して接続を開きます。サーバーは以前のクライアント・リクエストのレコードを保持しません。数千のクライアントがサーバーに接続することを想像してみると、どのセッションが自分か知る手段がありません。そこでセッションIDが登場します。セッションIDの交換を通して、ステートが保たれます。正確には何を意味するのでしょうか。同じセッションを再利用するために、全ての後続のRESTリクエストが、リクエストの”Cookie“ヘッダー内にsession 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分でそれより短くはできません。しかし、4directory/loginメソッドを伴ってPOSTヘッダー内へ渡すことのできる”session-4D-length”パラメータの値を使って、タイムアウトの長さを増やすことはできます。
おまけ
4D Serverは、前回のクエリーやオーダー・コマンドをベースにしたエンティティー・セレクションを保存しているセッションを持っています。そのため、データの次の”範囲”（あるいはチャンク）が必要なとき、クエリー/オーダーを再度行う必要がありません。シンプルにデータの次のセットを送るだけです。このメカニズムは、トランザクションやペシミスティック・ロックなどの使用を可能にしています。
次回予告
RESTサーバーは4D v18で大きく拡張され、将来にはさらに多くの機能が登場します。しばらくの間、サンプルや実際の使用例を提供する予定です。4Dフォーラムでの意見交換にご参加ください。