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フォーラムでの意見交換にご参加ください。
4Dは、あなたの4Dデータベースに保存したデータへ直接アクセスできる強力なRESTサーバーを提供しています。これによって、例えば、モダンなフロントエンド・テクノロジー(Angular、Reactなど)を使ったAPIの構築が可能です。このブログでは、4Dの堅牢なRESTサーバーを初めてご紹介します。また、APIテストツール、Postmanを使用して、作成、取得、更新、削除 (CRUD) の各操作をテストする方法を説明します。
注意:もしすでにRESTサーバーと4Dデータベースの構成方法をご存知の場合は、この後の2章はスキップしてください。
4D RESTサーバーを使えるようにするには、最初に構成が必要です(シングル・クリックで起動して動作します)。「データベース設定」の「Web / RESTリソース」ページの「RESTサーバーとして公開」にチェックするだけでRESTリクエストを処理することができます。
このステップは、すでにデータベースを作成してRESTサーバーを有効にしていると仮定しています。ストラクチャーに新しいテーブル [Tasks]とその2つの属性:Title (Alpha)とComplete (Boolean)を作成します。初期設定では、全てのテーブルはRESTで公開されます:
重要:テーブルとフィールド名はJSONに準拠(発音区別文字やスペースは不可)しなければなりません。
指示する方法は簡単です。WEBブラウザーを開いて、ADDRESS/PORTの後に”/rest”を挿入します。(全ての4D REST URLリクエストは/restで始まります。) 例えば、[Task]データクラスの全てのエンティティーを得たい場合は、以下のように処理できます:
4D RESTサーバーについて驚くべきことは、CRUD(とそれ以上の)操作をAPIが提供することです…では、見てみましょう! エンティティーの作成、読み込み、更新あるいは削除にあたっては1行のコードも必要ありません。全てがセットアップされています。よく知られているように、CRUDはデータベース操作の中で最も重要なグループです。ユーザーがデータを作成し、管理するのに必要なメインの機能だからです。
この驚異的なAPIをテストするために、Postman(RESTに最適のAPIをテストするための素晴らしいツール)を使います。Postmanは、GET、POST、PUT/UPDATE、DELETEや様々な他のリクエスト・メソッドのように、HTMLメソッドを作るための洒落たユーザー・インターフェイスを提供します。
注意:Postmanの使用は単純明快ですが、もし始めるにあたってヘルプが必要であれば、このビデオを見てください。
Postmanをダウンロードしたら、異なるリクエストを作ります。とても明快なリクエストから始めましょう。タスクのリストを([Tasks]テーブルから)検索します。前に述べたように、[Task]データクラスの全てのエンティティーを得るためには、ADDRESS/PORTの後に/rest/NameOfTheDatabaseを挿入します。
ご覧の通り、タスクのリストを検索するためには1行のコードも必要ありません
データクラスに新しいタスクを加えることもできます… これもコード不要です。 APIはすでに設定されています!
新しいエンティティーを作成するために、このURLは新しいポスト・リクエストを起動します: ADDRESS/PORP/rest/NameOfTheDataclass/?$method=update。それを実行するには、アプリケーションにJSONリクエストを送る必要があります。もしGETリクエストから結果をチェックすれば、新しいタスクを作成するのに必要な鍵となるアイデアが得られるでしょう。では、このロジックに従って、私たちにはタイトルと完全なフィールドだけが必要で、その他(キー、タイムスタンプ、スタンプ、ID)は4Dが対応します。
最初のタブ(GETメソッド)に戻り、送信をクリックしてタスクが追加されたことを確認します。4Dの出力フォームにも行き、新しいタスクが追加されているか確認します。
エンティティーを更新するには、エンティティーを作成したのと同じメソッドを使います。$method=updateは1つのPOST中の1つ以上のエンティティーを更新できます。それを実行するには、オブジェクトの中の_KEYと_STAMPパラメータを修正した属性とともに渡す必要があります。
サンプルでは、ヘミングウェイの不朽の名作のひとつ『老人と海』を読みました。従いまして、タスクのcompleteステータスをtrueに変える必要があります。簡単にできます:
エンティティーの削除もシンプルです。サンプルでは、ID=3 (“test”のコール)のタスクを削除します。問題ありません!deleteメソッドを呼び出して、そのIDを特定します:dataclass(ID)?$method=delete。
データベースに戻り、エンティティーが削除されてことを確認します。
ご覧の通り、4D RESTサーバーはとても強力です。たった今、デモしたようなこと以上にリッチなAPIを提供します。わずかな時間でできることはもっとあります。詳細な<a href=“https://developer.4d.com/docs/en/REST/%7BdataClass%7D.html“>ドキュメント</a>を参照してください。この先のブログで、認証についてのtipを共有し、その後で、4DデータベースへwebアクセスするためにAngular 7とRESTで書かれた完全なフロントエンド・アプリケーションも説明します。