Category: JavaScript

INTER-Mediatorでは、タグのdata-im属性に、「テーブル名@フィールド名」の形式で記述するターゲット指定により、そのタグ要素がデータベースのフィールドにバインドされて、データベースから読み込んだデータを表示し、フォーム用のコンポーネントであればユーザによる変更結果をデータベースに書き戻す事が自動的に設定されます。しかしながら、データベースとは関係ない記憶領域があると何かと便利です。言い換えれば、データベースにしか保持できないとなると設計の順内製がそがれます。そこで、クライアントサイドの計算フィールドを実装し、さらにローカルコンテキストという機能を実装しました。

ローカルコンテキストの利用方法

ローカルコンテキストとは、データベースと連動していない記憶領域で、テーブル名は一律に「_」を使います。フィールド名は任意の変数名でかまいません。Sample_searchでは、type属性がtextのINPUTタグに対して、<input type=”text” data-im=”_@placeCondition”/> という設定を行いました。placeConditionがローカルコンテキスト内の名前です。この記述をするだけで、テキストフィールドに一度入力したデータは、ページを更新しても必ず再現されます。イメージとしてはどこかに記録されて、それが必要に応じて自動的に復活すると考えてください。保存場所はクッキーの中です。

通常のコンテキストは、1つのコンテキストに複数のレコードがあり、そのレコード内にフィールドがあるという構造です。ローカルコンテキストは「レコード」という構造がありません。コンテキスト名も常に決まっているので、実質的にはシンプルなキーバリューストアと同一です。一般のコンテキストは、エンクロージャーとリピーターという繰り返しを誘発する階層構造をベースにしますが、ローカルコンテキストは1ページごとに1つずつ持っており、どこにどう書いてもかまいません。同一のフィールド名のタグ要素が複数あれば、それらでの編集結果も連動します。

ローカルコンテキストへの直接アクセス

テキストフィールドがある場合、そこに入力した値を取り出すのは、通常はgetElementById等を使ってノードを参照します。一方、ローカルコンテキストを利用したテキストフィールドなら、ローカルコンテキストから値を取り出すほうが確実です。たとえば、前述のinputタグ要素の場合、

var c1 = IMLibLocalContext.getValue("placeCondition");

とすれば、テキストフィールドに入れた値を取得できます。なお、テキストフィールドをローカルコンテキストに反映するタイミングは、フォーカスがはずれたとき、つまりonchangeイベントで行っています。もし意図的に値をローカルコンテキストに記録するには、

IMLibLocalContext.setValue("placeCondition", value);

と記述します。

計算式の中に、ローカルコンテキストのリンクノードを参照する記述「_@field」などがあった場合、他のコンテキストにあるフィールドと同様なルートで検索します。つまり、同一のエンクロージャーを探し、なければ上位のエンクロージャを探してその子孫のノードを検索します。

ローカルコンテキストは、URLにひもづくクッキーに記録し、とりあえず、期限は1年にしてみました。いろいろなタイミングで自動的にクッキーに記録し、一方でクッキーから取り出すので、ほぼ、そういうことは意識しなくてもいいのですが、この後に説明する件で、一部のブラウザで書き込みを明示的に記述しないといけない場合があります。

連動するプロパティ

こうして、ローカルコンテキストが稼働しているので、一部のプロパティについては、ローカルコンテキストで保持することにしました。

INTERMediator.startFrom = 0;
INTERMediator.additionalCondition = {};
INTERMediator.additionalSortKey = {};

これらは、前から順番に、検索結果の何レコード目から表示するのか、追加の検索条件、追加のソート条件となります。たとえば、ユーザインタフェースを使って、追加の検索条件を与えると、それがローカルコンテキストに記録されて、事実上永続化されます。検索条件は、随時適用されるので、検索条件を与えるといつまでもその条件が適用されるようになります。

これらの動作に関連する情報は、以下のキー名を使ってローカルコンテキストに保存しています。なお、_im_で始まるキーは、システム予約としておきます。今後、こうした記録が増える可能性があります。

_im_startFrom
_im_additionalCondition
_im_additionalSortKey

たとえば、検索条件を特定のコンテキスト「context」に対して設定する場合、例えば、次のように記述するのは、従来と変わりありません。

INTERMediator.additionalCondition['context'] = {
    field: 'zipcode',
    operator: 'LIKE',
    value: IMLibLocalContext.getValue("criteria") + '%'
};

このとき、背後では、ローカルコンテキストに右辺のオブジェクトを記録し、さらにクッキーへの記録まで同時に行います。

Internet Explorer 8での対処

Ineternet Explorer Ver.8のみ、プロパティに記録したデータを自動的に永続化する事ができません。IE8の場合のみ、INTERMediatorオブジェクトのstartFrom、additionalCondition、additionalSortKeyプロパティに設定した直後に、

IMLibLocalContext.archive();

という呼び出しを入れて、ローカルコンテキストに反映しつつ、クッキーへの保存を行うようにします。IE9以降や、その他のブラウザではこの呼び出しはなくてもかまいませんが、あっても問題はありません。ただし、同じ作業を複数回行うことになるので、効率は低下します。INTER-Mediatorの内部ではIEやそのバージョンの把握を行っているので、たとえば、次のように記述すれば、IE8の場合だけ、前述のメソッド呼び出しが実装できます。

if (INTERMediator.isIE && INTERMediator.ieVersion < 9) {
    IMLibLocalContext.archive();
}

表題の通りの仕組みを、INTER-Mediatorに組み込もうとして、２日ほどもがきました。RSAつまり秘密鍵と公開鍵を使った暗号化をフレームワークに組み込み、クライアントで入力したパスワードを、暗号化してサーバに送るという仕組みを組み込んでいます。普通パスワードはハッシュだろうと思われるかもしれませんが、フレームワークが認証するパスワードではなく、パスワードをデータベースエンジンへのアクセスに使うべく、クライアントで入力したものをバックエンドまで安全に到達させるための暗号化なのです。

RSAやハッシュ関連のことは、ネイティブな開発ならOpenSSLを使えばおおむねOKなので、同じようにライブラリを集めれば楽勝だろうと思っていました。また、PHPにはopensslライブラリがあるので、まあ、なんとかなるだろうと思いました。要件としては、キーの指定を簡単にするということ。つまり、公開鍵と秘密鍵が1つもPEM形式で得られれば、それを設定ファイルに書き込むことでキーの指定ができるということです。もちろん、生成は「openssl rsagen 1024」みたいなコマンドで簡単に済ませたいわけです。

JavaScriptの世界では、Dave Shapiroさんが作っているライブラリがあり、後々のいくつかのライブラリの多くはこれを改良しています。DaveさんのはPEM形式でキーを与えられないので、Tom WoさんのCrypticoが作られたようで、さらに別の人が署名までできるようにしています。Crypticoでいろいろやっていたのですが、うまくいかない…というか、単純にこのライブラリの問題ではなく、PHPのライブラリとの組み合わせの問題があったのです。

それで、PHPの方はというと、openssl関連関数があるので大丈夫かと思っていたら、これがなかなかうまくいかいないのです。まず、PEMでキーを与えるのが原則とすれば、Crypticoを使ってクライアント側で暗号化するのが手軽です。それを、PHPのopensslの関数で復号するのがどうしてもうまくいかないのです。そのあたりのドキュメントが今ひとつ詳しく書いておらず、コメントには「マニュアルは正しくない…」などと書いてある始末で、あれこれやってもだめでした。

ただし、PHPのopensslの関数を使えば、PEMの鍵データから、RSAの本来の鍵というか、計算式に出てくる鍵の数値をそのまま得られる事がわかりました。さらに、RSA: Encrypting in JavaScript and Decrypting in PHPというドンピシャなものがあったのですが、それはDave Shapiroさんのライブラリを使っていて、RSAの本来の鍵を使う方法が記載されています。ところが、このサイトに書いてあるPHPのライブラリはpearにあるCrypt_RSAで、説明に使っているものはすでのメンテナンスがなされていません。それを使う手もありますが、メンテナンスされているライブラリの方がいいかと思い新しいサイトへのリンクを見ると、なんとこれが、以前このblogでも紹介したPHPだけで作られたSSHのライブラリを含むphpseclib:に移行していたのです。SSHのライブラリはきわめて順調に動いたので期待をして、こちらのRSAを使って復号しようとしました。しかしながら、どんなにこねくり回してもだめなのです。このライブラリのサポートのBBSにあるこの書き込みと同じ場所でエラーが出ているようです。Macだとだめで、debianだと動くようなことが書かれているのが気になるところですが、この方法でうまく流すには簡単には行きそうにありません。

Dave Shapiroさんのライブラリで暗号復号するのはできます。また、phpseclib:で暗号復号はできます。つまり、異なるライブラリをまたいでの暗号復号がうまくいかないのです。Dave Shapiroさんのライブラリで暗号化したものを、opensslコマンドで復号してみると、パディングに関するエラーが出て復号できません。データ形式の微妙な違いがあるのでしょうか？　ドキュメンテーションの薄いライブラリや、あまりカスタマイズできないライブラリということで、これ以上手を下すことができず、ここで行き詰まってしまいました。

それで、改めてググって必死に探した結果、見つけたのがbi2phpというライブラリで、しかもMIT Licenseです。JavaScriptのライブラリは、Daveさんのものに独自に改良したものだそうです。それと互換でPHPのクラスを作ったというところでしょうか。いずれも、RSAの本来の鍵を指定するのですが、「データは全部HEX」というように、ある意味非常にわかりやすく、さくっとうまく行きました。

ということで、わかった事をまとめておきます。RSAの秘密鍵、公開鍵という仕組みはもういいとして、そこで使う鍵は、たとえば「openssl genrsa 1024」というコマンド入力で作られます。そのデータはPEMという1つのテキスト列であり、いわば、そこに秘密鍵と公開鍵などなど、RSA暗号処理に必要なデータがPKCSのルールに従ってパックされたものです。

$ openssl genrsa 1024
Generating RSA private key, 1024 bit long modulus
...................++++++
............++++++
e is 65537 (0x10001)
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQC/BlONnPUfSc95YmrcOUV0IbmeBZvibbAssetKBXAG0DGeKzc7
　　　　　　　:
2MgfcIZ3C7lf0+yx3/RhXwJBAIYHkht7UPSpPeTvPzc4v89yBlkkGeN9xLbdONT3
uzINAQkGvVmDhNLYqxkgDysBUy/Q2f41DenUZJfEFLQBs5w=
-----END RSA PRIVATE KEY-----

PHP側では、このPEM形式の文字列を使って、以下のプログラムで、RSAの計算に使うキーを求めることができます。$generatedPrivateKeyにはPEM形式のキーの文字列、圧縮アルゴリズムがAESの場合はパスフレーズを入れるので、その場合は$passPhraseに指定しますが、パスフレーズが設定されていない鍵は2つ目の引数は適当に無視します。

$res = openssl_pkey_get_private( $generatedPrivateKey, $passPhrase );
$keyArray = openssl_pkey_get_details($res);

この、$keyArrayの配列にいろいろなものが入っていて、公開鍵だけを取り出すには、$keyArray[‘key’]とします。

Daveさんのライブラリを使うには、鍵のオブジェクトを作成しますが、当然、自分で生成するのではなく、このPEMを鍵としてオブジェクトを初期化します。初期化関数部分は、次のように定義されています。biRSAKeyPairが鍵のクラス名と考えていいでしょう。

function biRSAKeyPair(encryptionExponent, decryptionExponent, modulus)

ここで、encryptionExponentは$keyArray[‘rsa’][‘e’]、decryptionExponentは$keyArray[‘rsa’][‘d’]、modulusは$keyArray[‘rsa’][‘n’]から得られます。生成した鍵からopensslのコマンドを使って出力（例えば、openssl rsa -text -in gen.key）した結果を見ながら、対応付けを確認しました。配列から得られた結果はバイナリなので、PHPの場合、bin2hex関数を使って16進文字列にして、JavaScript側の引数に指定をします。2次元目のeとdは、encrypt、decryptなんでしょうね。

なお、INTER-Mediatorでは、JavaScript側では暗号化しかしないので、2番目の引数は指定しません。というか、指定してクライアント側で見えたらいけません。なぜなら、$keyArray[‘rsa’][‘d’]は秘密鍵であり、暗号化には使わないからです。いずれにしても、JavaScriptのプログラムをサーバ側のPHPで生成してクライアントに送り込むという部分がこうした処理を組み合わせて作る事ができます。

bi2phpのPHP側のクラスは、JavaScriptとほぼ同様なプログラムでいいようになっており、サンプルのHTMLを見ればプログラムの作り方はすぐにわかると思います。非常に紆余曲折がありましたが、JavaScriptとPHPの双方で暗号復号をするには、bi2phpというライブラリでOKということです。ただし、PHPのopenssl関数を使って、PEMから鍵の値を得たりということは処理として必要になるということです。このライブラリをまとめたAndrey Ovcharenkoさんに感謝するともに、ライブラリをここまで育て上げたみなさんに感謝します。