メソッドのSQLパートは,4Dランゲージの実行コンテキストからトランザクションレベルを継承します。たとえば,4Dパートでトランザクションを開始した場合,SQLもトランザクション内で実行されます。SQLパートでエラーが発生し,トランザクションがキャンセル(ロールバック)された場合,4Dランゲージの実行コンテキストもトランザクションが中止されることになります。これは仕様です。
v16以降の64ビット版クイックレポートエディター(QR SET AREA PROPERTY
コマンド)は,下記のプロパティをサポートしていません。これは仕様です。
qr view color toolbar
qr view column toolbar
qr view menubar
qr view operators toolbar
qr view standard toolbar
qr view style toolbar
現在,サポートされているプロパティはqr view contextual menus
のみ,となっています。
Folder
コマンドには,ファイルシステムパス(例:"/PACKAGE"
)または定数(例:fk database folder
)を渡すことができます。コンポーネントからホスト側のパスを取得するには,アスタリスクオプション(*
)を指定します。このオプションが使用できるのは,定数でパスを指定した場合だけです。この点は,ドキュメントに明記されています。ファイルシステムとアスタリスクオプションを組み合わせて使用することはできない点に留意してください。
CLEAR VARIABLE
は,変数または配列をクリアするコマンドです。インタープリターモードでは,2次元配列の要素もクリアできるかもしれませんが,これは従来の振る舞いを変えないための特別な措置であり,コマンドに2次元配列の要素を渡すことは想定されていない点に留意してください。
コンパイルモードで配列の要素をCLEAR VARIABLE
でクリアすることはできません。2次元配列の要素は,変数(配列)とは違います。DELETE FROM ARRAY
を使用してください。
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サーバーを開始する方法をご覧いただきました。Postmanを使って異なるCRUD操作を経験し、完全なるRESTドキュメントへと導きました。今回のブログでは、4Dの中でセッションがどのように働くのかを説明します。これを理解することで、4D RESTサーバーを使ったセッションベースの承認システムの構築ができることを確信しています。
認証システムの構築を目指すなら、あなたの探しているものはセッションベースのシステムです!
4DRESTサーバーへの接続は、セッションベースです。これは、4Dサーバーがセッションを作るのは、最初のリクエストがクライアント(WASID4D)によって送られ、セッションクッキーが返送された時であるということです。全てのサブスクエント・リクエストに対して、クライアントはリクエストへのヘッダー中のセッションクッキーを返さなければなりません。これは、サーバー側にはセッションが残っていないけれどクライアント上に保存されている、トークンベース認証とは反対になります。
では、セッションの扱い方をよく理解できたところで、さらに前進します。始める前に、4D RESTサーバーを開始しえて、構成します。さらに始める前に、このブログあるいはドキュメントセンターを参照してください。
データベースメソッドのOn REST Authenticationによって、4D上でRESTセッションの開き方のコントロールをカスタマイズする方法が使えるようになります。RESTセッションを開くリクエストを受けた時、接続確認(例:ユーザー名とパスワード)がリクエストのヘッダーに提供されます。On REST Authenticationデータベースメソッドが呼ばれるので、これらの認証を評価でき、True(セッションの開始を承認)あるいはFalse(セッションの開始を拒否)を返します。
注記:このデータベースメソッドがデータベースへの独自のアクセスコントロールのコーディングに使われている間、アクセスは4Dユーザー・グループを使って制限することも可能です。データベースを表示している際に、データベース設定 > Web > RESTリソース・タブにアクセスを許可されたグループを選択します。このブログで記憶を取り戻してください。
セッションの開始を図解するには、ログインとパスワードを伴うサブミッション・フォームを想像しましょう。POST リクエストのヘッダー内の認証情報を送るのにPostmanを使っています。RESTを通じて4Dアプリケーション内のセッションを開くために、$directory/login:を使います。
4Dに戻ってどうなるか見てみましょう。
ご覧の通り、データベースメソッドはパラメータを受け取ります。
注記:現実には、パスワードはハッシュされて、暗号化されていない状態で送られることはありません。ハッシュされたパスワードを送るには、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フォーラムでの意見交換にご参加ください。