ぐらめぬ・ぜぷつぇんのはてダ

2008/11/24以降のメインブログはこちらになります。 : http://www.glamenv-septzen.net/

本はてなダイアリにはコメント・トラックバックを受け付ける記事を公開します。

2008-03-06

[]Xhwlay-0.9.3をリリースしました。

Fix Xhwlay_Bookmark_FileStoreContainer's gc() bug and test case bugs.

no title

Bookmarkデータファイルがいつまで経っても消えないなぁ、おかしいなぁと首をかしげてたのですが、調べてみたらBookmarkデータファイル名を"bcdata"とかにしたタイミングで、gc()でのファイル名リストアップでヒットしなくなったため、消されてなかったようです。

しかもテストケースも、ちょうどgc()のテストのとこだけ"_"付けて無効化してたし。

何の為のSimpleTestだよ、って感じ。

とりあえずバグFixアップデートでした。

2008-02-22

[]Xhwlay-0.9.2を(改めて)リリースします。

前回の0.9.2のリリースなんですが。

http://d.hatena.ne.jp/msakamoto-sf/20080216/1203164097

0.9.2じゃ無かったです。0.9.1でした。すみません。パッケージファイルとかは0.9.1になってたのですが、SourceForgeに登録したニュースのTitleとかが0.9.2になってました。

http://xhwlay.sourceforge.net/ja/

で、今回改めて0.9.2をリリースします。と言いましても変更点は一箇所だけで、XhwlayはPEAR::Error_Stackを使っていますが、今までINFOで出していたメッセージを全部DEBUGに直しただけです。

いえ、実際に実務で使っててファイル保存までべらべらINFOでログに出すのはうざいな、と。いやError_Stackですのでpackageで切り替えるというのもアリなんですが、ちょっとアプリ側の一部でもXhwlay_ErrorStack使ってますので混ざるので、いろいろと面倒くさいのでこうなりました。

2008-02-16

[] Xhwlay-0.9.2をリリースしました。

木曜日、仕事でトラブった・・・のだけれど意外とすんなり終わったので、その深夜、0.9.2をリリースしたのを忘れてた。

Fix file locking problems in FileStoreContainer.php and change 'button' tags in "sample" code to 'input' normal submit button tags.

Add some features which make xhwlay's applications more secure, and add "sample2" example.

no title
  • サンプルコードの中でIE系で思うように動かないbuttonタグを用いていた箇所を通常のinputボタンに修正しました。
  • ファイルストアの場合、内部でファイルをロックしていなかった為同時にアクセスした場合ファイル内容が壊れる可能性があったのを、flock()によりロックするよう修正しました。
  • ファイルストアの場合、BCIDの期限切れチェックと妥当性チェックをするようにしました。
    • 期限切れ:最後にアクセスした時刻からの秒数を超過していた場合はBCIDを再発行します。
    • 妥当性チェック:ファイルストアクラスのコンストラクタでパラメータに'identKeys'を指定することで、IPアドレスやセッションIDとのペアを比較して(より)正当(だと思われる)クライアントからのリクエストかチェックします。
  • 'identKeys'を用いたより安全(だと思われる)サンプルコードを"sample2"ディレクトリに追加しました。

という地味なリリースです。特にbuttonタグについては自分が阿保としか思えない・・・。IEでまともに動かしてなかったから。

只これで、おおよそ実用レベルに引き上げられたと思います。で、実際今とあるお仕事で使用中。

で、Xhwlayだけじゃ足りないのですが実に個人的な趣味の問題でやっぱり独自フレームワークを用意する羽目に。

xwt : Xhwlay Web application Template

CakePHPとSymfonyを足して、2 100位で割った=機能劣化版です。いや、例により激しく使いやすいですヨ?

余計なDBマッパーは無いし(そもそも用意してない。PEAR_DBだろうがMDBだろうがADODBだろうが好きに用意して使ってくれ(w)、セッションは強制的に開始されるけどぶっちゃけXhwlayを使おうと使わなかろうと全く関係ない手抜きっぷり。単にモジュールのdispatcher.phpにコントローラでforwardしているだけ。dispatcher.phpの中では何しようと一切関知せず。Xhwlayを使おうが単にViewを表示してお仕舞いだろうが、何だったらCakePHPのエントリポイントにしようが何でもアリ。要するにエントリポイントがrequireするファイルは只のディスパッチャで、後は全部ユーティリティクラス。URLの構造も決め打ち(というかXhwlayでBCIDをURLに入れる為、流行の"?"を使わない構造に出来なかった)。

現在開発中の某仕事が落ち着いて、コードがまとまったら近日中にSVNにUPります。

2007-12-01

[][]編集画面でのTicketの導入について再考。

というか初めて考えているわけですが。

YakiBikiの記事の編集画面は、Xhwlayが当初予定しているよりも単純で、それ故にXhwlayが適用できない形になった。

えっと、Xhwlayが「向いている」のはこんな画面フローです。

(1) 詳細 --> (eventA) --> (2) 更新フォーム --> (eventB) --> (3) 確認フォーム --> (eventC:更新) --> (1) へ戻る
         --> (eventD) --> (4) 削除確認フォーム --> (eventE:削除) --> (1) 或いは一覧画面へ戻る

IDを総当たりされてeventCまたはeventEを送り込まれても、未発行のIDであれば新規フローとして(1)に初期化され、そのためeventC/eventEは(1)が受け付けないイベントとして無視されます。

次のようなフローにはXhwlayは弱いです。

(1) 更新フォーム --> (eventA:更新) --> (2) 更新完了お知らせ

2画面で、最初の画面で発生するイベントが破壊的な操作を行う場合です。これですと、IDを総当たりされてeventAが送り込まれると、新規フローに初期化されます。ところが、(1)はeventAを受け付けられますのでeventAが発動してしまい、破壊的操作が実行され、そのまま(2)に移ってしまいます。

ですので、画面フローをどう繋げるかが、Xhwlay(多分Pieceも例外じゃないとは思うのですが)を活かせるか否かの分かれ目になります。


逆に上のような2画面、あるいは次のような1画面構成の場合、状態保持云々よりは単純にいわゆるCSRF対策向けのTicket機構を導入した方が良いように思われます。

(1) 編集フォーム --- (POST:更新) --- (1) へ戻る

実はYBの記事の編集画面などが全部このパターンです。つまり、Xhwlayが適用できない。

えっと、つまり、ID総当たりされた場合Xhwlayではフローを「作って」しまうのです。望ましいのは「未発行のIDは拒否」です。うーん、Xhwlay自体も、未発行のIDが来たらIDを再生成して返す位の事はさせたいですね。

それはそれとして、また、二重POSTを判別する為には、使い終わったTicketも暫くは補完しておかなければなりません。おそらく、直近N個のTicketは覚えておき、新しいのが来たら古いのを捨てていくようにする必要があるでしょう。Xhwlayの場合、BookmarkがEndに達したフロー情報は即座に破棄していますので、これができません。あと、有効期限も必要です。Xhwlayも必要かな・・・。

イメージとしてはこんな感じです。"new"というスロットと"used"というスロットがあり、usedにはN個、Ticketを格納できるとします。今回は3個とします。

今、新しいTicketを一つ請求します。

<new>
[ Ticket#1 ]

<used>
[          ][          ][          ]

もう一つTicketを新規請求します。

<new>
[ Ticket#1 ][ Ticket#2 ]

<used>
[          ][          ][          ]

ここでTicket#1を使用済みにすると・・・

<new>
[ Ticket#2 ]

<used>
[ Ticket#1 ][          ][          ]

となります。この時点で再度Ticket#1を使ったリクエストがあっても、二重送信として無視すればいいわけです。

暫く後このような状態になったとします。

<new>
[ Ticket#4 ][ Ticket#5 ]

<used>
[ Ticket#3 ][ Ticket#2 ][ Ticket#1 ]

ここでTicket#4が使用済みになると、usedスロットから一番古いTicket#1が破棄され、代わりにTicket#4がusedスロットに入ります。

<new>
[ Ticket#5 ]

<used>
[ Ticket#4 ][ Ticket#3 ][ Ticket#2 ]

・・・とまぁ、こんな感じの動きをしてくれれば最高ですね。ちなみにこの状態でTicket#1のリクエストが来た場合、二重POSTではなく、単に未発行IDとして無視します。

あと、「Ticketは未使用か?」と「Ticketを使用済みにする」はトランザクションでロックしなければなりません。

というのも、もしロックせず、バラバラで動かせるようにしてしまうと次のように、僅差で同じIDのリクエストが通ってしまう可能性があるからです。

<t1>
reqA(ticket#1) ---> 「Ticketは未使用か?」:Yes

<t2>
reqA(ticket#1) ---> 「Ticketは未使用か?」:Yes ---> 「Ticketを使用済みにする」:処理開始
reqB(ticket#1) ---> 「Ticketは未使用か?」:Yes(タイミングの問題)

<t3>
reqA(ticket#1) ---> 「Ticketは未使用か?」:Yes ---> 「Ticketを使用済みにする」:Done ---> ...
reqB(ticket#1) ---> 「Ticketは未使用か?」:Yes ---> 「Ticketを使用済みにする」:処理開始

きちんとロックし、使用済みに更新する処理が完了するまでは他のrequestはwaitさせるようにする必要があります。

<t1>
reqA(ticket#1) ---> (LOCK_EX){「Ticketは未使用か?」:Yes }

<t2>
reqA(ticket#1) ---> (LOCK_EX){「Ticketは未使用か?」:Yes ---> 「Ticketを使用済みにする」:処理開始 }
reqB(ticket#1) ---> (WAIT)

<t3>
reqA(ticket#1) ---> (LOCK_UN){「Ticketは未使用か?」:Yes ---> 「Ticketを使用済みにする」:Done } ---> ...
reqB(ticket#1) ---> (LOCK_EX){「Ticketは未使用か?」:No }

・・・というようなのを実装しないとだなーと思いました。が、ちょっとまだ見えない部分もありますので、当面はTicket無しで進めたいと思います。一通り出揃ってから改めて考えれば良いかな、と。それまではCSRFもろ喰らう事になりますが。

2007-11-22

[]突発的な妄想

なんか、無条件に"success"を返す、いわゆる「ダミーイベントハンドラ」が欲しくなってきた・・・。

[Xhwlay::onAlwaysSuccessEvent]
function onAlwaysSuccessEvent(...) {
    return "success";
}

こんだけのやつ。・・・yb_Xhwlayにちょっと入れてみよう。

2007-10-12

[][] Xhwlay-0.9.0(beta)をリリースします。

イベントドリブンなページフロー制御ライブラリの"Xhwlay"、そのPHPによる実装であるxhwlay-phpの最初のbetaバージョンをリリースします。バージョンは0.9.0です。

簡単にまとめたWebコンテンツも同時にリリースしますので、ご興味のある方はご覧下さい。

http://xhwlay.sourceforge.net/

Xhwlay-0.9.0はPEARでインストールできます。インストール後、PEARのdocsディレクトリに sample が入ります。これに関する簡単なPDFのチュートリアルドキュメントも書いてみました。PDFのDLは、上のURLの日本語ページから入手できますので、こちらも宜しければどうぞ。

5月に着想、6月からコーディング、7,8月でテストコードやチュートリアルドキュメントで四苦八苦、9月は仕事で忙殺されつつもPseudo_BlockでPEARのパッケージ作成方法を勉強、9月の最後で家の都合でめちゃくちゃドタバタしてPHP勉強会もドタキャンの憂き目に遭った10月だけど、ローカル環境でようやくPHP5とPHP4を並列して動かせるようになって、PHP4とPHP5で動作確認取れて・・・。

長かった。ようやくです。

でも、ここから、ようやく、YakiBikiが始まります。