2007-07-02

d:id:ZIGOROu:20070327:1174986131 の続きです。
随分サボってましたorz...

OpenID Authentication 2.0 - Draft11 - Data Formatsがソースです。

プロトコルメッセージ

OpenID Authentication protocolのメッセージはプレインテキストのキーと値の対応で表されます。キーと値はUnicode character set(UCS)が許可されています。キーと値がバイト列に変換されたり、バイト列に変換されたりする必要があるとき、UTF-8でエンコーディングされていなければなりません。

メッセージは同じ名前の複数のパラメータを含めてはなりません。name.

この文書を通して出てくる全てのOpenIDのメッセージパラメータは必須で、特に記載がないものはオプションです。

Key-Value フォームエンコーディング

キーと値のフォームの中のメッセージは一行ごとに記載されます。それぞれの行はキーから始まり、コロン(:)を続け、キーに結び付けられた値を記載します。その行は1つの改行で終了され(UCSのコードポイントで10、"\n"のこと)ます。キーあるいは値は改行を含めてはならず、そしてキーはコロンを含めてもいけない。

追加の文字で、空白文字を含む場合、コロンあるいは改行の前後に含めてはならない。メッセージはバイト文字列で提供される場合UTF-8でエンコードされていなければならない。

キー-値のフォームエンコーディングは署名の計算、そしてRelying Partiesへの直接的な応答*1の為に使われます。

HTTP エンコーディング

メッセージがHTTPサーバーに送られたとき、メッセージはHTML4.01で示される17.13.4節で示されるフォームエンコーディングを使ってエンコードされていなければならない。*2

リクエストメッセージの中の全てのキーは"openid."と言う接頭辞を持たねばならない。この接頭辞はOpenID Authenticateメッセージと共に渡される他のパラメータとの干渉を防ぐ。メッセージがPOSTとして送られたとき、OpenIDパラメータはPOSTのbodyの中で送らねばならず、またそこから展開されなければならない。*3

HTTPリクエストとして送られる全てのメッセージは下記のフィールドを全て含まねばならない。

openid.ns

Value: "http://specs.openid.net/auth/2.0"

この特別な値はリクエストが妥当なOpenID Authentication 2.0のリクエストであることを表す為にある。将来の仕様のバージョンはそのリクエストをきちんと解釈するメッセージの受信者の許可に従って異なる値を定義しても良い。

もしこの値が省略されているか、"http://openid.net/signon/1.1" または "http://openid.net/signon/1.0" が設定されていた場合、このメッセージはOpenID Authentication 1.1の互換モードと解釈すべきである。

openid.mode

Value: それぞれのメッセージタイプを明示した値

"openid.mode" パラメータはその処理がどのような種類のメッセージかをメッセージの受信者が知る事を許可する。もし "openid.mode" が省略されていた場合、Relying PartyはそのメッセージをOpenIDのメッセージではないと仮定して処理すべきである。

このモデルはRPからOPへのメッセージだけでなくUser-AgentからRP, OPへのメッセージにも適用される。

例

標準化されていない状態

下記の例を下記の情報にエンコードする。

Key     | Value
--------+---------------------------
mode    | error
error   | This is an example message

キー-値のフォームエンコードは、

mode:error
error:This is an example message

x-www-urlencodedでエンコードし、HTTP POSTメソッドの本文またはURLのquery stringを使う。

openid.mode=error&openid.error=This%20is%20an%20example%20message

整数型の再表現

意図的に正確さを求める整数を扱う場合、2の補数を表示し、ビッグエンディアンとしてエンコードされなければならない。以後、"btwoc" は意図的に正確な整数を取り扱い、そして2の補数で再度定義された最も短いビッグエンディアンを返す関数である。Diffie-Hellman鍵共有と共に使われる全ての整数は正数である。この意味は2の補数で再表現されたデータの左端のビットがゼロでなければならない事を意味する。もしそうでなければ、実装系ではゼロバイトを文字の先頭に付け加えなければならない。

標準化されていない例

基準となる10進数 | btwoc による再表現
-----------------+----------------------------
0                | "\x00"
127              | "\x7F"
128              | "\x00\x80"
255              | "\x00\xFF"
32768            | "\x00\x80\x00"

*1:原文では5.1.2 Direct Responseへリンク。まだ読んでないので詳細不明

*2:つまるところ、application/x-www-form-urlencodedの事。この後を読む限りmultipart/form-dataは駄目？

*3:つまりPOSTのときはQUERY_STRINGは無視しろと言うこと。

といってもまだCPANには反映されてないと思いますが、一応cspageってコマンドを付けてみました。0.02から使えます。
機能としては、

HDFファイルの生成
HDFファイル化する際の文字列ダンプ
HDFファイルとCSファイルからレンダリング
指定した変数群からCSファイルをレンダリング

と言う機能を付けました。これで気軽にClearSilverが楽しめるはず。

分かる人はピンと来ただろうけどTTにあるtpageコマンドの廉価版みたいな感じです。（ぉぃ

HDFファイルの生成

$ cspage --define name=zigorou --define url=http://d.hatena.ne.jp/ --output-hdf=test.hdf
$ cat test.hdf
url = http://d.hatena.ne.jp/
name = zigorou

HDFファイル化する際の文字列ダンプ

--output-hdfオプションを付けない場合は、ダンプになります。

$ cspage --define name=zigorou --define url=http://d.hatena.ne.jp/ 
url = http://d.hatena.ne.jp/
name = zigorou

HDFファイルとCSファイルからレンダリング

$ cspage --input-hdf test.hdf test.cs 
ZIGOROu

  bar is true

指定した変数群からCSファイルをレンダリング

$ cspage --define foo=amachang --define bar=0 test.cs 
amachang

まとめ

ここまで作っといてなんだけど、実際にClearSilver使うかどうかはまだ決めてないです。
用途によりけりかなーと。

試しにってのは全然ありかなとは思ってますし、
何より色んな言語で使えるテンプレートってのはいいかなーと思ってたりします。

あと、可能な限りフレームワークとの結合を排す事が出来たら、
すなわち渡す変数に依存性を出来る限り設けないようにしたら、
異なる言語間でも同様のテンプレートファイルが使えるかもなとか思ってたりします。

これはやはり記法もシンプルで出来る事が限られていると言う所がこの場合はメリットにもなるんだと思います。

日向夏特殊応援部隊

俺様向けメモ

斜め読みOpenID Authentication 2.0 - Draft11 (4) Data Formats