FileMaker Server 14をOS Xで稼働するときのWebのカスタマイズ

以前に、FileMaker Server 13とOS X ServerのWebという文書で、FileMaker ServerのWebを動かすための方法を書きましたが、そこで、.htaccessファイルなどを有効にする方法記述しました。しかしながら、FileMaker Server 14.0.4を新たにインストールした場合、前記の文書の記述だとエラーが出ることがわかりました。この点は、FileMaker Server 14のどのバージョンでも当てはまるようです。

ということで、設定ファイルはHTTPServer/conf/httpd.confは以下のように変更すれば良いでしょう。

<Directory "${HTTP_ROOT}/htdocs">
    AllowOverride All
    Options All -Indexes -ExecCGI -Includes
    Require all granted
</Directory>

FileMaker Server 13のとき、「Order allow,deny」「Allow from all」も、Directoryタグ内に書いていたのですが、これを書くと、こんなエラーが出ました。最初のエラーにより、ステータスは403が返り、もちろん、ブラウザでは何も出てきません。後半の「an unknown filter was not added: includes」のエラーは派生的なもの、あるいは副作用的なもののようです。

[Sun Nov 29 01:00:40.179248 2015] [authz_core:error] [pid 1534] [client 219.121.7.182:38310] AH01630: client denied by server configuration: /Library/FileMaker Server/HTTPServer/htdocs/index.php
[Sun Nov 29 01:00:40.179642 2015] [core:error] [pid 1534] [client 219.121.7.182:38310] AH00082: an unknown filter was not added: includes

それから、ディレクトリへのアクセスで、index.htmlよりも先にindex.phpを開きたい場合のDirectoryIndexディレクティブの設定は、上記のDirectoryタグのすぐ下にあるdir_moduleが組み込まれた場合の設定にあります。しかしながら、ここを変えても意図通りに動かないなと思ったら、/Library/FileMaker Server/Web Publishing/publishing-engine/php/yosemite/httpd.fmi.conf.phpの最後の行にあるDirectoryIndexディレクティブを修正しないといけないことが分りました。

Apacheの設定ファイルは、バージョンが違うとそこそこ違ったりしますし、管理手法も比較的変動が大きく、「以前使えた設定や手法が通用しない」ということはこのところ頻繁に経験します。注意しましょう。

[IM]INTER-Mediatorワークショップで作った“イベント参加申し込みサイト”

K-OFのイベントの1つとして、INTER-Mediatorのワークショップを2015年11月7日に開きました。ワークショップとなると、参加者の皆さんに手をうごしてもらって…というのが一般的ですが、その場で参加される方々もいらっしゃったので、手を動かすのはプレゼンターだけでやりました。

今回のワークショップでの開発目標は、イベントの参加申し込みです。別の勉強会での事後アンケートで、「こういうのを作りたい」と希望があり、それを題材にさせていただきました。グループカウンセリングを実施している赤石さんは、現在、フォームズというサービスで参加受付を行い、メールで送られてくる参加依頼の内容を1項目ずつコピー&ペースとしているそうです。当初は「コピペをしないで一発でExcelに入れる」という要望だったのですが、いっそのこと、受付フォームと一覧表示をINTER-Mediatorで作成するのはどうかということで了承していただき、それをワークショップの題材としました。なお、実際の運用サイトでは、以下のコード内にあるパスワードや一部の名称はもちろん変更しています。

12191812_909228155821822_1194109405261025992_n

設計内容とスキーマ

ざっくり書いたユーズケース図は次の通りです。アクターは、赤石さんと、グループカウンセリングに参加される「お客様」の2つです。お客様はブラウザで申し込みをして、その結果をメールで受け取ることになります。その申し込み結果を「申し込みリスト」に蓄積して、それを赤石さんは随時チェックするという流れになります。この時、お客様は認証等なく申し込みを行えるようにしますが、一方で赤石さんしかリストが見れないようにします。ここで、データベースへの新規レコードは認証なし、その他の処理は認証を行わないとできないようにするという基本設計もできてしまいます。また、システムとアクターの接点は2か所あり、それぞれ1ページだけで実現しそうなので、合計2つのWebページの作成で済みそうです。

ユースケース図0

ER図と同じ用途のクラス図は次のようになります。ちょっとシンプルですが、「申し込み」という1つのテーブルで作ります。本来、グループカウンセリングの実施が1つのエンティティになり、カウンセリングのテーブルを作成して、申し込みとイベントが多対1の関係を作ります。現状では1種類のイベントを、シーケンシャルに、つまり同時に複数のイベントの募集をしているといった事情もないので、1テーブルで運用します。言い換えれば、イベントには「開催日時」というフィールドしかないので、別テーブルにする必要性は薄いということです。「義援金支払い許諾」はチェックボックスで、受講条件の1つを許諾するかどうかを明確にするものです。「ユーザー情報」は、INTER-Mediatorで認証を実施するために必要なテーブル群です。

クラス図0

これらを実現するMySQL用スキーマとして、以下の記述を作成しました。実はワークショップでは、これに失敗して悩んでしまったのですが、今後のワークショップはこれを雛形にしましょう(苦笑。ユーザーやデータベースを定義してアクセス権を設定し、applyテーブル(クラス図での「申し込み」)を定義します。その後の、authuser、authgroup、authcor、issuedhashのテーブルは認証で必要とするものです。リスト表示の時に使用するuser1ユーザーのみ定義しています。

SET NAMES 'utf8mb4';
#DROP USER 'web'@'localhost';
CREATE USER 'web'@'localhost' IDENTIFIED BY 'password';
DROP DATABASE IF EXISTS akaishi;
CREATE DATABASE akaishi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE akaishi;
GRANT SELECT, INSERT, DELETE, UPDATE ON TABLE akaishi.* TO 'web'@'localhost';

CREATE TABLE apply (
  apply_id INT AUTO_INCREMENT,
  name VARCHAR(100),
  yomi VARCHAR(100),
  email VARCHAR(100),
  address VARCHAR(255),
  content TEXT,
  agreement INT,
  startdt DATETIME,
  PRIMARY KEY(apply_id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

CREATE TABLE authuser (
  id INT AUTO_INCREMENT,
  username VARCHAR(48),
  hashedpasswd VARCHAR(48),
  email VARCHAR(100),
  limitdt DATETIME,
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

INSERT authuser SET id=1,username='user1',hashedpasswd='d83eefa0a9bd7190c94e7911688503737a99db0154455354';

CREATE TABLE authgroup (
  id INT AUTO_INCREMENT,
  groupname VARCHAR(48),
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

CREATE TABLE authcor (
  id INT AUTO_INCREMENT,
  user_id INT,
  group_id INT,
  dest_group_id INT,
  privname VARCHAR(48),
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

CREATE TABLE issuedhash (
  id INT AUTO_INCREMENT,
  user_id INT,
  clienthost VARCHAR(48),
  hash VARCHAR(48),
  expired DateTime,
  PRIMARY KEY(id)
) CHARACTER SET=utf8mb4, COLLATE=utf8mb4_unicode_ci, ENGINE=InnoDB;

申し込みページの作成

まず、お客様がイベントの申し込みを行うページを作ります。コンテキストの定義を含む定義ファイル(apply.php)は以下のようなものです。ポストオンリーモードでのページを作成すればいいので、コンテキストは1つだけです。また、新規レコードは認証なしで、その他のデータベース処理はできないようにしたいので、存在しないユーザー(nobodyknows)に対してのみ読み出し、更新、削除ができるようにして、事実上、これらの3つの処理は行えないようにします。authenticationキーにcreateキーの値がないので、createに関しては認証なく実施できます。オプション指定はなく、データベース指定のところに、dsn、user、passwordのキーで、データベースへの接続についての記述を行っています。

<?php
require_once('../INTER-Mediator/INTER-Mediator.php');

IM_Entry(
  array(
    array(
      'name' => 'apply',
      'table' => 'apply',
      'view' => 'dummy',
      'key' => 'apply_id',
      'post-reconstruct'=>true,
      'authentication' => array(
        'read' => array('user' => 'nobodyknows'),
        'update' => array('user' => 'nobodyknows'),
        'delete' => array('user' => 'nobodyknows'),
      ),
      'send-mail' => array(
        'create' => array(
          'from-constant' => "msyk@msyk.net",
          'cc-constant' => "msyk@msyk.net",
          'subject-constant' => "申し込みを受け付けました",
          'to' => "email",
          'body-template' => "confirm.txt",
          'body-fields' => "name,yomi,email,address,content,startdt",
        ),
      ),
    ),
  ),
  array(),
  array(
    'db-class' => 'PDO',
    'dsn' => 'mysql:host=localhost;dbname=akaishi;charset=utf8mb4',
    'user' => 'web',
    'password' => 'password',
  ),
  false
);

お客様が申し込みを行うページのぺージファイル(apply.html)は次のように定義しました。見出しの文字列は最低限にしていますが、実運用の時には書き直して利用していただくとして、INTER-Mediatorの動作に関わる部分だけを作ってあります。ヘッダ部での定義ファイルの読み込み、BODYタグのonload属性でのフレームワーク呼び出し、そしてボディ部での記述がポイントになります。ボディ部では、TABLEタグによるテーブルが定義されていますが、data-im-control属性により、ポストオンリーモードであることが指定されています。あとは、コンテキストとフィールド名のセットをdata-imに記述します。同意の項目はチェックボックスですが、value=1の指定があり、チェックがあれば1をフィールドに設定します。カウンセリングの日付はstartdtフィールドにしますが、ここの部分はお客様が入力するのではなく、募集するときに日時が決定しているので、その日時を初期値として規定し、INPUTタグ自体はreadonly属性を設定して、表示だけをするようにします。最後のBUTTONもdata-im-control属性を指定して、書き込みボタンにします。なお、定義ファイルのコンテキストにはpost-reconstructキーのみがあり、この場合は書き込みを行うとこのページの再ロードを行うので、そこで入力した結果が消えます。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <title>Title</title>
  <script type="text/javascript" src="apply.php"></script>
</head>
<body onload="INTERMediator.construct();">
  <table>
    <tbody data-im-control="post">
      <tr>
        <th>名前</th>
        <td><input type="text" data-im="apply@name"/></td>
      </tr>
      <tr>
        <th>名前の読み</th>
        <td><input type="text" data-im="apply@yomi"/></td>
      </tr>
      <tr>
        <th>メールアドレス</th>
        <td><input type="text" data-im="apply@email"/></td>
      </tr>
      <tr>
        <th>住所</th>
        <td><input type="text" data-im="apply@address"/></td>
      </tr>
      <tr>
        <th>相談内容</th>
        <td><textarea data-im="apply@content"></textarea></td>
      </tr>
      <tr>
        <th>同意</th>
        <td><input type="checkbox" value="1" data-im="apply@agreement"/></td>
      </tr>
      <tr>
        <th>日程</th>
        <td><input type="text" data-im="apply@startdt" 
                   value="2015-11-07 13:00:00" readonly/></td>
      </tr>
      <tr>
        <th></th>
        <td><button data-im-control="post">申し込む</button> </td>
      </tr>
    </tbody>
  </table>
</body>
</html>

定義ファイルapply.phpのコンテキストには、レコードを作成した時にメールを送信する設定が組み込まれています。そのためのメールの文面は、confirm.txtファイルに以下のように用意します。メールについては、定義ファイルでの定義通り、差出人、CC、件名は決められたものを設定し、送り先は作成されたレコードのemailフィールドを指定します。本文は、以下のconfirm.txtの中の@@1@@などの部分が新規に作成されたレコードの値に置き換わります。body-fieldsキーの値に列挙されたフィールドとその順番より、@@1@@が名前、@@3@@がメールアドレス、@@5@@が相談内容、@@6@@が開催日時を示します。

@@1@@ 様(メールアドレス:@@3@@)

以下の通り、グループカウンセリングのお申し込みを受け付けました。

開催日時:@@6@@
ご相談内容:
@@5@@

_(などなど必要な情報を追加する)_

作成したページは次のようなものです。

shot3036

申し込みを行うと、入力したメールアドレスに、確認のメールが送られます。

shot3041

一覧ページの作成

一覧ページを構成するために、以下のような定義ファイル(list.php)を作成しました。こちらは、applyテーブルの内容を参照したり、場合によっては変更や削除等があるので、すべてのデータベース操作に対して、user1で認証したユーザーだけが許可されるようにしました。また、開催日の逆順で一覧されることで、最近の開催日に対する参加者がリストの上部にまとまるようにしました。コンテキストには、削除ボタンの追加の指示はありますが、挿入ボタンはありません。挿入ボタンは、必要ならapply.htmlから自分で申し込みを入れてそれを修正すればいいと考えました。

<?php
require_once('../INTER-Mediator/INTER-Mediator.php');

IM_Entry(
  array(
    array(
      'name' => 'apply',
      'table' => 'apply',
      'view' => 'apply',
      'key' => 'apply_id',
      'paging' => true,
      'records' => '20',
      'repeat-control' => 'confirm-delete',
      'sort' => array(
        array('field' => 'startdt', 'direction' => 'desc'),
      ),
      'authentication' => array(
        'all' => array('user' => 'user1'),
      ),
    ),
  ),
  array(),
  array(
    'db-class' => 'PDO',
    'dsn' => 'mysql:host=localhost;dbname=akaishi;charset=utf8mb4',
    'user' => 'web',
    'password' => 'password',
  ),
  false
);

一覧のページファイル(list.html)は以下の通りです。特に変わったところはなく、applyコンテキストの内容をページネーションとともに表示をしています。コンテキスト定義にあるように、20レコードずつ表示をします。

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <link rel="stylesheet" href="INTER-Mediator/Samples/sample.css" />
  <title>Title</title>
  <script type="text/javascript" src="list.php"></script>
  <style>
    td{
      border: solid 1px black;
    }
  </style>
</head>
<body onload="INTERMediator.construct();">
  <div id="IM_NAVIGATOR"></div>
  <table>
    <thead>
      <tr><th>開始日時</th><th>名前</th><th>読み</th>
        <th>住所</th><th>相談内容</th><th>同意</th><th></th></tr>
    </thead>
    <tbody>
      <tr>
        <td data-im="apply@startdt"></td>
        <td data-im="apply@name"></td>
        <td data-im="apply@yomi"></td>
        <td data-im="apply@address"></td>
        <td data-im="apply@content"></td>
        <td data-im="apply@agreement"></td>
        <td></td>
      </tr>
    </tbody>
  </table>
</body>
</html>

ページを表示すると、ログインパネルが表示されます。

shot3042

正しいユーザー名とパスワードを入力してログインすれば、リスト形式で、申込者の一覧を見ることができます。

shot3043

ワークショップを終えて

結果的にワークショップでは、入力専用(ポストオンリーモード)のページと、その入力した結果を表示するための2つのページを作成しました。実際のワークショップでは凡ミスに気づかずちょっと時間を無駄しにしてしまって申し訳なかったのですが、通常ではこれくらいであれば1時間程度の作業で行えるということが示せたかと思います。また、典型的なシステム開発の流れも見ていただけるサンプルになったかと思います。

なお、こうして作ったシステムも、作ってから新たなニーズが発生するかと思います。そうした追加の要求や変化する要求についても追跡させてもらって、可能な限り、アフター・ワークショップとしてお伝えできればと考えています。

[IM]JavaScriptのメソッド内関数だけをテストする

INTER-Mediatorだけの話ではなく、JavaScript一般的な話です。メソッドの中に、そのメソッドの中だけで使う関数を書くということが可能なので、INTER-Mediatorではそういう実装をあちらこちらでやっています。処理の多いメソッドでは関数に分離することで見通しが良くなりますが、加えて、メソッド内の関数レベルでのテストをするということも考えました。

以下のプログラムで、変数anObjectはあるオブジェクトを参照しています。オブジェクトはmethod1というメソッドがあり、そのメソッドの中で、内部の関数であるfunc1を呼び出しています。このプログラムにより、コンソールには、”method1″ “func1″と2行の出力が行われます。

var anObject = {
  prop1: null,
  method1: function() {
    console.log("method1");
    func1();
    // method1のその他の処理
    function func1() {
      console.log("func1");
    }
  }
}

anObject.method1();

ここで、func1だけをテスト対象にしたく、かつmethod1の実処理を行いたくないと考えたとします。その場合、次のようにプログラムを変更しました。このプログラムは、こちらのページの記載を参考にしました。

var bObject = {
  prop1: null,
  method1: function(isTesting) {
    console.log("method1: isTesting="+isTesting);
    this.func1 = function() {
      console.log("func1");
    };
    if(isTesting) {
      return;
    }
    this.func1();
    // method1のその他の処理
  }
}

bObject.method1();
(new bObject.method1(true)).func1();

ポイントは、内部関数func1をプロパティにしていることです。そして、テストか通常利用かを示す引数isTestingを追加します。この引数は省略すると、undefinedになりますので、テスト時はtrueを追加するとして、省略時は何も指定しないことにします。テストの時には、プロパティへ内部関数の設定だけを行い、メソッドはそのまま終了します。

最後からの2行目は、普通にmethod2を利用する場合を想定しており、コンソールには、”method1: isTesting=undefined” “func1″と出力されます。この記述は、最初のプログラムの最後の行にある「anObject.method1();」と全く同じで、method1はつまりは通常利用では何も変更せずにそのまま利用できます。

一方、一番最後の行の実行により、コンソールには”method1: isTesting=true” “func1″と表示されます。newがあることでmethod1をコンストラクタとして実行するので、メソッド自体を返し、その結果、func1関数がメソッドのように実行できます。コンソールに”func1″と表示するのは、method1内部のthis.func1()を実行している部分ではありません。isTesting編集がtrueなので、その前にmethod1は終了します。つまり、「(new bObject.method1(true)).func1();」という記述で、func1だけを実行できるので、この関数だけの単体テストができるということです。

ちなみに、この方法は、method1に引数があっても利用できます。

[IM] OAuth2あるいはOpenID対応

Google AppsのOAuth2対応について、Using OAuth 2.0 to Access Google APIsに説明されています。この認証方式をサポートしました。したがって、OAuth2対応およびOpenID対応と言えるかと思います。Google以外のプロバイダについては今後、確認します。まずは、認証できるようになっているので、その使用方法を説明します。

OAuth認証するクライアント

まず最初に、ページをOAuth対応にした場合にどんな感じにページ表示されるのかを示します。認証を必須にすると、INTER-Mediator内蔵のログインパネルが表示されそこに「OAuth認証」というボタンが登場します。ここで、ボタンをクリックします。

shot2712

初めて利用するときには、次のように、認証アカウントから何を取り出すのかを表示するメッセージが出てきます。ここで「許可」をクリックします。なお、複数のアカウントでログインしている場合には、さらにどのアカウントでログインするのかを問い合わせるページもこの前に表示されます。

shot2713

そして、認証されます。おなじみのサンプルのページです。ログインユーザーは、ここでは意図的にプロバイダーによって提供される一意な名前とプロバイダー名を@でつないであります。

shot2714

認証のデータベースを見てみると、そちらに新たにユーザーが追加されています。つまり、外部にあるユーザーの認証ではありますが、いったん、利用しているデータベースのauthuserテーブルに、ユーザーを作り、もっぱらauthuserテーブルのユーザー情報を利用して、認証を行います。一定時間で無効化しますが(今日現在未実装)、それまでは、OAuth認証直後にランダムに生成したパスワードをクライアントに通知して記憶させ、INTER-Mediator自身の認証処理を行うことで、都度都度OAuthサーバーとのやりとりはないようにします。

shot2715

Googleでのアカウント発行

GoogleのOAuth2を利用するためには、アカウント発行が必要です。このアカウントは、アプリケーション、つまり、INTER-Mediatorで作るページに対するアカウントです。ページの利用者はこれらの情報は不要ですし、見えるようにする必要はありません。

まず、Googleデベロッパーのコンソールページに移動します。ここで、「プロジェクトを作成」をクリックします。このページは、もしかすると、2つ先のような画面になっているかもしれません。その場合はページの中にある新規プロジェクトを作成するようなボックスがあるので、それをクリックします。

shot2701

プロジェクトの作成で指定するのはプロジェクト名のみです。もちろん、開発者が把握できる名前を指定して、「作成」ボタンをクリックします。

shot2702

このようなページになります。追加したプロジェクトが1つのボックスになっています。また、左側に見えるように、このページが「ホーム」です。初めての利用であれば、このページに行きますが、以前い何か利用していた場合ではこの限りではありませんので、臨機応変に対処しましょう。ここまでで、ともかく1つのプロジェクトを作成してください。

shot2703

プロジェクトのボックスの右下にある「V」マーク部分をクリックすれば、内容が開きます。ここで、「プロジェクトの詳細」をクリックします。

shot2704

左側のナビゲーションで、APIと認証にある、「認証情報」をクリックします。認証情報というパネルが出るので、「認証情報を追加」をクリックします。

shot2705

ドロップダウンから、「OAuth 2.0クライアントID」を選択します。

shot2706

このような画面になります。「同意画面を設定」をクリックします。ここの同意画面は、最初に認証するときに見える画面です。

shot2707

メールアドレスはGoogleアカウントのメールアドレスが設定されています。サービス名を適当に記述しますが、この名前がタイトルになります。その他は「省略可」であるので、認証の動作には影響しません。入力をして「保存」ボタンをクリックします。

shot2708

アプリケーションの種類は「ウェブアプリケーション」を選択します。そして、「名前」は一覧の中で識別する名前を適当に指定します。そして、承認済みのJavaScript生成元には入力せず、承認済みのリダイレクトURLに、ここではINTER-Mediatorに含まれている/Auth_Support/OAuthCatcher.phpのURLが示されています。実際に利用するときには、このファイルのコピーを作るなどしてもかまいませんが、このまま利用してもかまいません。ログインパネルの「OAuth認証」ボタンをクリックすると、Googleが指定する「トークンリクエスト」のURLに移動し、ユーザーの特定や取得可能な情報のアクセス許可をページ上で求めます。その後に、「承認済みのリダイレクトURL」にリダイレクトするときに、アクセストークンが引数として渡され、INTER-Mediatorはそれを元に、OAuthユーザーをデータベースに作成します。

shot2709

「作成」ボタンを押すと、クライアントIDとクライアントシークレットが表示されます。これらはparams.phpファイルにコピペをします。コピペの方法は後で説明します。(ご安心ください。このIDとシークレットはすでに無効化してあります)

shot2710

OKをクリックすると、発行したアイアウントが一覧されるページになります。ここから、削除や追加、あるいは変更などのアカウントの管理もでき明日し、同意画面の変更などもできます。

shot2711

INTER-Mediatorで作成するファイル

OAuth認証を使いたいページでは、まず、定義ファイルに基本的な設定を行います。例えば、以下のファイルは、Samples/Sample_Auth/MySQL_definitions.phpの記述です。IM_Entryの第2引数に、authenticationキーで連想配列を指定します。とりあえず、クレデンシャルの記録方法(ここではセッションストレージ)とレルム(ここでは「Sample_Auth/MySQL_definitions」)を指定します。レルムは単に同一認証を受け付ける領域名とと考えてください。

IM_Entry(
    array( /* コンテキスト定義 */
    array(
        'authentication' => array(
            'storing' => 'session-storage',
            'realm' => 'Sample_Auth/MySQL_definitions',
        ),
    ),
    array('db-class' => 'PDO'),
    2
);

Googleに関連づける情報は、params.phpファイル側に記述できます。これらは、定義ファイルでは記述できないのが現在の仕様です。それぞれ、以下のように、決められた変数名に値を指定します。最初はプロバイダーで現在は「Google」のみサポートしています。続いて、クライアントIDトクライアントシークレットを、Googleのデベロッパーコンソールのページからコピー&ペーストします。最後のリダイレクトのURLは、「承認済みのリダイレクトURL」と同じURLを指定します。

$oAuthProvider = "Google";
$oAuthClientID = '1084721348801-jv3hvi4shcmr4j7unuhioq8k2mm47n6s.apps.googleusercontent.com';
$oAuthClientSecret = 'hV5TZD8x108K1Zac4RfZopur';
$oAuthRedirect = 'http://localhost:7001/Auth_Support/OAuthCatcher.php';

まだ完成というまでには至っていませんが、ともかく、認証できるところまでを作りました。タイムアウトのタイミングや、カスタマイズポイントなどを作りこみたいと思いますが、ご意見があれば、Facebookのグループでよろしくお願いします。

El Capitanのイチオシ機能はSplit View

年中行事となったOS Xのアップグレードですが、それだけに「大した違いはない」という感想を持ってしまいがちです。しかしながら、2015年10月リリースのEl Capitan(OS X 10.11)のSplit Viewはとても注目できる機能です。一部のiPadでiOS 9により実現していた機能なので、iOSの方が少し先になりましたが、複数のアプリケーションを使い分けるMacでこそ真価が発揮できそうな注目の機能です。

要するにこんなことができます。画面全体に表示されている感じを示すために、画面ショットに外枠も追加してみました。

右は編集中の原稿をJeditで見ているところです。左側はそれをブラウザのChromeで見ているところです。画面にはこの2つのアプリケーションの画面があるだけで、他のアプリケーションはありません。右で入力や変更をして保存、左側をクリックして更新とある程度の操作は必要ですが、ウインドウの大きさは固定であり、スクリールをするだけで、位置を調整したりということしなくても、2つのアプリケーションを並行して快適に利用できます。

shot0001f

こちらは、左がで開発ツールのPHPStromを使い、右側のブラウザ(Chrome)で実行しながらデバッグするという状況です。どちらのアプリケーションもさらにペインに分割されて多数のペインになっていますが、こういう作業でウインドウの前後関係を気にしないで作業できるのは非常に快適です。

shot0002f

使用方法は次の通りです。まず、利用したいウインドウを2つあらかじめ用意しておきます。そして、3本指でトラックパッドを画面方向にスワイプするMission Controlを利用します。すべてのウインドウが画面いっぱいに重ならないように表示されます。そして、1つのウインドウを画面上の「デスクトップ1」などと見えているデスクトップが並ぶ箇所(背景画像がボケて見える箇所)にドラッグします。何もないところにドラッグします。以下の図ではグラフィックス表示していますが、最初は文字のみです。マウスポインタを画面の上の方に移動させれば、グラフィックスも表示されます。

shot2695

デスクトップと同じ大きさのグレーのボックスが表示されます。これが出ることを確認してからトラックパッドの押し込みを放すなどして、ドラッグを終了します。

shot2696

すると次の図のように、もう1つデスクトップが確保されますが、アプリケーション(この場合PHPStorm)が最大化された状態で追加されます。

shot2697

続いて別のウインドウを先ほど新たに作ったデスクトップの上の右半分(あるいは左半分)のあたりにドラッグして追加します。追加される場所が濃いグレーで応答しますので、ドラッグを終了する前に、画面の状況を確認しながら作業をしましょう。

shot2698

こうすれば、2画面に分割したデスクトップが1つ確保されます。Mission Controlの画面でクリックして切り替えてもいいですが、2本指で左右にスワイプして、デスクトップを切り替える方が、快適に切り替わるでしょう。アプリケーションの境界線をドラッグして、左右に移動することもできます。ディスプレイが複数台あれば、それぞれのディスプレイで、内容の異なるSplit Viewを構成することもできます。ちなみに3つのウインドウまではできません。同一アプリケーションの2つのウインドウであれば、Split Viewで表示できます。

Macだと複数のアプリケーションを行き来することはよく行います。マルチウインドウシステムはそうした作業に適合するとはいえ、たくさんのウインドウが折り重なるデスクトップは混乱の元です。切り替わるべきウインドが前面に来るはずが、全然違うウインドウが出てきてがっかりすることも多々あります。作業の上で「それぞれのウインドウを見る」となると、今まではウインドウの位置や大きさをユーザーが調整していたのですが、そういう使い方ではマルチウインドウよりスプリット形式に表示する方が見やすく効率がいいのは、多くのアプリケーションで実証されています。そして、その仕組みをOSがサポートすることで、アプリケーションを超えて1つの画面に集約できる機能がやっと使えるようになったということです。Split ViewはiOSの系譜があるとはいえ、Macにとっては新しいインタフェースを加えるものであり注目できる機能と言えるでしょう。

[IM]追加の検索条件のマッチング

INTER-Mediatorでのページ状態の記憶の仕組みについて、幾つかの変更を行っています。変更前に動作の基本として、ローカルコンテキストは、ローカルストレージ(使えない時はクッキー)に保存をするようにしています。ローカルコンテキストには、ページファイル内にあるdata-im属性が「_@fieldName」のデータの置き場所を確保します。加えて、INTERMediator.addConditionメソッドでクエリーに追加する検索条件も、INTERMediatorオブジェクトのプロパティに見えるものの、実際にはそれをローカルストレージに保存しています。その結果、ページを開いた時にはローカルストレージは復元されるので、追加する検索条件も一度与えると明示的に消さない限りは、そのページに戻ったときに復元され、つまりは検索条件が常に保持されるように見える仕組みが組み込まれています。

ここで、ローカルストレージのキーに、URLを含めていましたが、URLのうちのクエリー部分は排除すべきかと考えました。例えば、ページファイルを開くときに渡すパラメータを与えて「page.html?id=101」などといったURLがある場合、ローカルストレージのキーに「page.html?id=101」までを含めるのか、「page.html」だけを含めるのか、どっちがいいのか(正しいのか?)を考えましたが、後者ではないかと思ったのです。クエリー部分があると、クエリーの内容によって以前の検索条件が消えるというのは、動作として正しくないと考えました。

ところがこうすると、こんな問題が発生します。例えば、page.htmlはクエリー部の情報を検索条件として付与するとします。「page.html?id=101」により、id=101という検索条件が加わり、ローカルコンテキストに保持されて残ります。そして、「page.html?id=55」をアクセスしたとき、どちらもpage.htmlなので、id=101という検索条件が残ったまま、id=55が付与されます。つまり、id=101 AND id=55というように、追加の検索条件が設定されてしまいます。idが主キーなら、検索されるレコードは0になってしまいます。これは意図しない動作です。

この問題には正解はないと思いますが、ロカールストレージのキーにクエリー部を含むURLを入れてしまうと、クエリー部によって、保持されるかどうかの挙動が変わってしまうことになります。一方、クエリー部を含めないでキーにすると、検索条件が追加されてしまって、意図しない動作になります。

そこで考えたのが、追加する検索条件については、マッチングをするということです。ローカルトレージのキーには、クエリー部は含めません。しかし、すでにid=101を検索条件として記憶している時に、addConditionメソッドで条件を追加するときには、条件のオブジェクトのfieldおよびoperatorプロパティが同一のもがあれば、その値のみを置き換えるようにします。id=55を追加すると、id=101とid=55のfieldおよびoperatorは同一なので、id=55の方だけが残るようにします。なお、こうした動作ではなく、従来と同様に単純に追加したい場合は、addConditionの3つ目の引数にtrueを指定することで、マッチングをしないで追加をするようにしました。ここまでをすでに実装しました。

そして、INTERMediator.clearConditionは、ローカルコンテキストの追加検索条件をクリアしていますが、同時に、ローカルストレージもクリアするのが正しいのではないかと考えています。すぐに実装は可能です。

[IM] OAuth2 (Open ID)による認証の実装

現在の認証方式は、[IM]INTER-Mediatorの認証フレームワーク(2)に記載の通りですが、これのベースにOAuthを動作させたいと考えています。ということで、とりあえず、Googleをベースに考えてみました。ブログなどでよく見られる「Google対応」は、2.1、4.1、4.2の部分です。Googleで認証をした結果を取り出すという部分です。しかしながら、そこから後が長いですね。その認証で得られた情報を元に、アプリケーション自体の認証もしなければなりません。OpenIDのtoken_idをそのままクッキーに入れるといった実装も見られますが、実際の認証はすでに動作しているユーザー名とクレデンシャルを使った方法を利用します。Open IDのtoken_idがあれば、その署名の検証を行うことで、内容を信頼するようにしようかと考えています。一番、問題なのは8.4で、クレデンシャルの期限切れがあったときに、クレデンシャルを問い合わせるか、あるいは再生成して再設定するかを行うことになると思います。その時、token_idの中身を見て、ユーザー名を特定することで、確実に動作してくれないかと考えています。ご意見よろしくお願いします。

シーケンス図0

[IM] バリデーションをどう実装するのか?

バリデーションに関しての実装は、バリデーションの実装を再考するや、Facebookのメッセージにも書きましたが、なんとなく実装が見えてきた感じがするので、一度ドキュメントにしてみたいと思います。

まず、UIからDBまで線を引いて、チェックポイントがどれだけあるかというと、これだけあります。もちろん、もっと細かくできますが、要するに出入りの部分となるとこうなります。

  1. テキストフィールドなどのデータがあるUIコンポーネント
  2. 送信ボタン等、データはないけど、データ送信を指示するUI
  3. AJAXの出口(Adapter_DBServer.js)
  4. サーバー側の受け入れ(DB_Proxy.php)
  5. データベースエンジンのスキーマに定義する制約

現状では、定義ファイルのコンテキスト定義に含めるvalidationキーによる連想配列の配列を設定することで、原則として、1そしてPost Onlyモードでの2のバリデーションが機能します。

ここでまず、3は不要と考えます。言い換えれば、4があるなら3はいらないということになります。5はフレームワーク外のものです。その有無とフレームワークの動作をどの程度連携させるのかは難しいですが、ここでポイントは「5はなくてもアプリケーションとして要求を満たせる」使用にしておくということです。

ちなみに、2は、Post Onlyモードと、IM_Entry関数のオプション変数でtransactionキーをnoneにして「保存」ボタンを表示した時になります。ここで、1つ考えられることは、1と2は同時に満たすようにはすることはまずないということです。もし、やりたい場合、「保存」ボタンでは現状APIはありませんが、Post Onlyモードはデータベースアクセス前に呼び出すメソッドを実装して、そこに機能を組み込むことができます。ということは、1と2は排他的であると言えるのではないでしょうか。

そうなると、(1 or 2) (4) [5] がチェックポイントになります。[5]については、データベースのエラーの扱いに含まれることになりますので、(1 or 2) (4) のチェックポイントが残ります。

そういうわけで、次のような使用を考えてみました。

A. validationキーの設定により(1)の状況を必ず満たす

validationキーの設定のあるフィールドとバインドした編集可能なUIコンポーネントは、フォーカスが外れた時に必ずバリデーションを行います。編集中のページはもちろん、Post Onlyモードでもそうします。また、初期値が違っている場合は、そこを変更しようとしてフィールドにフォーカスしたあと、そのまま別のフィールドに移動する時にチェックします。つまり、初期値はチェックしないのに等しいでしょう。

B. post-validationキーにより、(1)をやめて(2)にする

コンテキストに、新規に用意したpost-validationキーの値がtrueなら、(1)の状況ではチェックはせず、(2)の状況のみ、validataionキーで定義した内容に基づきチェックを行います。validation/notifyの指定がないフィールドが1以上ある場合、それらのメッセージをまとめて1つのダイアログボックスで表示します。post-validationキーの値が文字列の場合、ダイアログボックスで表示する。つまり、すべてのエラーメッセージをノードに表示したとしても、通知のためのダイアログボックスを出す手法を用意しておきます。

C. server-validationキーにより、サーバー側のバリデーションを有効化する

コンテキストに、新規に用意したserver-validationキーの値がtrueなら、サーバー側でvalidataionキーで定義した内容に基づきチェックを行います。notifyについては無視して、エラーをクライアントに返します。このキーの指定により、クライアントとサーバーの両方でチェックすることになる。ただ、こちらはエラー取得後の動作が悩ましいですね。

D. 外部キーフィールドの参照整合性のチェックは、ruleに特殊な関数あるいは記述で指定

外部キーフィールドにテキストフィールドを仮に利用したとしたら、こういう設定が欲しいかもしれません。しかし、よく考えると、そういう場合、ポップアップメニューにすれば解決するとおもいます。SELECT文のIN演算子の右側が欲しいわけですから、結果的にデータを取り出すコンテキストとフィールド名の指定が必要です。ただし、データベース接続が増えることや、レコードの増減を反映させることなどを考えれば、この仕様は優先度低いかなと思っています。

E. 複数のフィールドにまたがる検証はvalidationキーの指定を工夫する

例えば、{field: “f1, f2”, rule: “value1 != ” and value2 != ” “, message:”?”} ように、validationキーの連想配列の指定を複数に拡張します。

キータイプごとの検証や、検索条件の適用はしないことにします。A.はほぼ実装できていますが、B、C、D、Eはまだです。この中で、優先順位的にはB-C-E-Dというところでしょうか。

さて、これらの使用でいかがでしょうか?

[IM] SQLの集計処理をサポート

INTER-Mediatorは宣言的な設定やあるいは動作上の状況から自動的にSQLステートメントを生成します。通常のリレーション取得はそれでもいいのですが、集計処理などでは、SQLのチューニングが必要になります。そこで、コンテキストにaggregation-select、aggregation-from、aggregation-group-byという3つのキーをサポートするようにしました。これらのキーがあると、viewキーはSQL生成では無視されます。また、読み込み処理のみをサポートするので、tableキー、keyキーは実質的に使われません。aggregation-select、aggregation-fromは両方とも指定する必要があります。これらのキーを設定すると、コンテキストからの読み込みに次のようなSQLを生成します。

SELECT [aggregation-selectの値]
FROM [aggregation-fromの値]
WHERE [query, relation, その他による検索条件]
ORDER BY [sort, その他によるソート条件]
GROUP BY [aggregation-group-byの値]
LIMIT [recordsの値]
START [オフセット値]

つまり、SELECT、FROM、GROUP BY句については、新たに導入したキーの値を利用します。aggregation-selectにSUM()などの集計関数による記述が使えるので、キーの名前にaggregationを含めています。もちろん、自動生成できないうなSQLの生成は集計だけに限りません。WHERE、ORDER BY、LIMIT、STARTはすでに組み込まれている様々な指定方法が反映されます。WHRE句は、コンテキスト定義のqueryだけでなく、relationキーによる関連レコードの検索、JavaScript上での追加条件の設定、ローカルコンテキストを利用した追加設定を利用できます、これらはすべてが実行されるSQLステートメントに反映されます。ORDER BY句も同様、コンテキストのsortだけでなく、JavaScriptやローカルコンテキストの指定も加わります。

なお、STARTについては、引き渡しは実装しましたが、現状では0でのみ利用してください。つまり、ページネーションは利用できないということです。パフォーマンスを考慮して、レコード数のカウントは、SQLの結果の数と同じにしてあるので、結果的に1ページ分しか出てこないでしょう。これは、後々改良をすることとします。

この機能によるパフォーマンス向上の効果を説明しましょう。例えば、大量の売り上げデータがあって、月ごとに集計したいとします。集計する方法は、SQLだけでなく、計算プロパティを使う方法ありますが、大量なので、処理を効率的にしたいため、データベース側で集計したいとします。aggregation-*キーがない場合には、月ごとの売り上げ集計結果が1レコードとなるようなビューを作成しておき、検索条件(例えば、年と月を指定)をビューに適用することになります。しかし、そのような動作だと、一旦ビューを構築するために全部のデータの集計を行うこともあり、一部のデータだけを使うという動作にならず、十分なパフォーマンスが得られません。しかし、aggregation-selectに「SUM(price)」のような記述が含まれていれば、WHERE句で対象月に絞り込んでクエリーを実施した上で集計されるので、全部のデータを取り出して処理をするということはなく、より最適化されたSQLが発行されます。

FROMを独立して指定できるようにしているので、ここに、「テーブル名 JOIN テーブル名 ON 条件」という記述によるテーブル結合もできます。aggregation-*キーはそのまま指定されるようになっていて、とりあえず、現状ではフィールド名のクォートなどはしていません。セキュリティ的に問題になる可能性もありますが、クライアントのユーザーによって改変できない内容なので、構築時に注意をしておけば基本的には問題ないでしょう。

サンプルは、Samples/Sample_Extensible/aggregation3.htmlです。サンプルの選択ページでは、「Aggregation Query」という列を作り、そこにサンプルページのリンクを作ってあります。

[IM]LDAP認証の実装がだいたいできてきました

INTER-Mediatorには、自分自身でユーザーテーブルを持つ認証(ビルトイン認証)が可能です。そして、データベースエンジンのユーザーによる認証(ネイティブ認証)もすでにサポートしています。次に取り組むのはやはりLDAPです。ただ、MySQLにはLDAP接続のプラグインがあり、そういう手法を使えば、ネイティブ認証の一環としてLDAP認証を実現することができます。しかし、通常とは異なるデータベース運用が必要になりますし、MySQLとPostgreSQLで動作に違いがあるとまた大変です。SQLiteはそういう統合はできません。LDAPについては、単に認証の確認だけだと、要するに認証バインドをするだけのことであり、PHPではさほど難しくはないので、データベースエンジンと独立してLDAP認証の仕組みを搭載しました。

LDAPサーバに対する設定

まず、LDAPサーバ情報は、params.phpファイルに、変数で記載する方法にしました。LDAPでの認証時は、ユーザーはユーザー名だけを与えるのではなく、ユーザーレコードのDN(Distinguished Name)を指定する必要があります。たとえば、OS X Serverで、ホスト名がhomeserver.msyk.netの場合、

uid=msyk,cn=users,dc=homeserver,dc=msyk,dc=net

というのがユーザーを特定するDNとなります。ここで、dc…以降は「検索ベース」、cn=usersは「コンテナ」とします。さらに、OS X Serverはuidという属性名でユーザー名を指定しますが、これもActive Directoryでは違うこともあって、結果的に上記のユーザー名「msyk」以外の部分をすべて、変数で与えて、DNを構成するようにしています。サーバーのURL、ポート番号も合わせて、結局、params.phpファイルに以下のように記載をすることにします。

$ldapServer = "ldap://homeserver.msyk.net";
$ldapPort = 389;
$ldapBase = "dc=homeserver,dc=msyk,dc=net";
$ldapContainer = "cn=users";
$ldapAccountKey = "uid";

なお、$ldapServer変数に設定されている文字列の長さが0以上なら、LDAP認証を試みるように動作します。これらの変数部分を全部コメントにすると、LDAP認証に関しては何も行わず、以前の通りの動作になるようにしました。

PHPのLDAPライブラリの機能を使って認証するとしたら、その認証のためのバインドはサーバーからLDAPサーバーに送られます。ということは、クライアントからサーバーに対して、ユーザー名とパスワードを送り届けないといけません。これは、ネイティブ認証の仕組みを利用しますが、そのために、鍵ペアを生成して、params.phpファイルに記述します。以下の部分です。もちろん、最初から入っている鍵ではなく、コメントに書いている方法で自分が使用する鍵に置き換えてください。もちろん、クライアントに送られるのは、公開鍵です。

$generatedPrivateKey = <<<EOL
-----BEGIN RSA PRIVATE KEY-----
MIIBOwIBAAJBAKihibtt92M6A/z49CqNcWugBd3sPrW3HF8TtKANZd1EWQ/agZ65
 :
jU6zr1wG9awuXj8j5x37eFXnfD/p92GpteyHuIDpog==
-----END RSA PRIVATE KEY-----
EOL;

ネイティブ認証との混合動作

そして、LDAPアカウントでのログインは簡単にできました。ただし、1回の認証バインドに0.2〜0.3秒ほどかかります。同一のサブネットです。たとえば、フォームのサンプルだと、1ページの合成にデータベースアクセスを15回ほど行うので、5秒くらいのアクセス時間の増加になります。これは、ちょっと長いです。また、単に認証ができたとしても、グループ設定との連動等といった問題があります。

そこで、LDAPアカウントで認証が成功したら、ビルトイン認証で使うテーブル(authuserテーブル)に、そのLDAPのアカウントの情報をレコードとして追加することにしました。1回成功したら、ビルトイン認証テーブルにユーザーを追加し、パスワードもわかっているのでハッシュ化したパスワードを保存します。そのために、ビルトイン認証を行って失敗するとLDAP認証を行うという流れにしました。ビルトイン認証とLDAP認証は切り替えるのではなく、この順序で両方行います。
しかし、その追加したユーザーがいつまでも使えるのは問題で、タイムアウトさせないといけません。そこで、結果的にはビルトイン認証のテーブルにDateTime型のフィールド「limitdt」を追加する必要が発生しました。現在の実装では、そのフィールドの有無で落ちることはないようにしてありますが、LDAPを使う場合には追加したフィールドの定義がされていないといけません。

こうしてユーザーのレコードを作っておくと、グループへの登録ができます。ユーザー名で識別され、1度登録すると消されないので、主キー値は保持されるはずです。タイムアウトすると、LDAP認証を試みます。ただ、この部分、現在実装中で、うまくいったりいかなかったり、一進一退ですが、ある程度のところまで動くようになっています。ちなみに、MoodleもLDAP認証をサポートしますが、ログインを1度することで、ユーーザーレコードが作られる仕組みになっており、やはり同じような仕組みをINTER-Mediatorでも実装しています。

認証処理の流れ

初めて、LDAPアカウントでログインしようとするとき、ビルドイン認証のテーブルにはそのユーザーはありません。したがって、ビルトイン認証では失敗しますが、その後のLDAP認証で成功します。このとき、新たにビルトイン認証のテーブルに、そのユーザーのレコードを作りパスワードのハッシュと期限を記録します。クライアント側には認証のための情報が残されているので、この次の通信時からは、自動的にビルトイン認証が成功します。したがって、1画面作るのに20回の通信処理が必要でも、最初の1回だけがLDAP認証されます。

次の通信処理が、LDAP認証のタイムアウト以内の期間なら、ビルトイン認証が成功して終了します。そのとき、limitdtフィールドも現在の時刻に更新します。しばらくクライアントを利用しないなどでタイムアウトになると、ビルトイン認証は失敗しますが、引き続くLDAP認証が成功するように、クライアントでは、LDAP認証とネイティブ認証に必要な情報が残されています。そして、1度LDAP認証に成功すると、次回以降はまたネイティブ認証がタイムアウトまで成功します。

認証に必要な情報はクッキーに保存することもできるので、翌日にまた認証を継続させることもできます。

今現在、動作が怪しいのは、LDAP認証のパスワードを変えたときです。まず、この方法だと、LDAP認証のタイムアウトの時間が来るまでLDAPでの認証は行われないので、その期間は変更前のパスワードが通ります。これは、とりあえず、仕方ないことの1つとしておきます。そして、タイムアウトしてLDAP認証すると、当然ながら以前のパスワードでは認証が通らないので認証エラーとなり、ログインパネルが表示されます。ここで、新しくなったパスワードを入力すると、また同じように動作するというのが期待する動作です。このあたりの挙動が現状、今ひとつな感じです。

FileMakerはサポートせず

なお、LDAP認証は、PDOのみで、FileMaker Serverはサポートしません。どうしようかと思ったのですが、Admin Consoleでの設定で「外部サーバーアカウント」をクライアント認証で使えるようにしておけば、ネイティブ認証で事実上、Active Directory、Open Directoryは利用できます。LinuxのLDAPは使えないけど、FileMakerのクライアントで使えないで、Web側だけで使える仕組みまでのサポートは必要かどうか疑問ですので、FileMakerはINTER-Mediator組み込みのLDAP認証はサポートしないということにしたいと思います。