PEAK XOOPS - gticket2リリース in englishin japanese

Archive | RSS |
XOOPS
XOOPS : gticket2リリース
Poster : GIJOE on 2006-05-06 04:50:43 (13354 reads)

in englishin japanese
チケットクラスXoopsGTicketを新しくしました。
このgticket2では、チケットエラーが起きた時の再投稿フォームを実装しました。
この機能は、ユーザのストレスを軽減してくれるはずです。
(30分以上もかけて書いた投稿がチケットエラーで一方的にはねつけられて、コピペの機会も与えられないなんて、ショック以外の何物でもないですから)

gticket2の使い方は従来とまったく一緒です。

- include/gtickets.php に置いたクラス定義ファイルを読み込みます
- フォームにチケットを埋め込みます
- フォーム処理側で、check()関数を実行します


●XoopsFormに埋め込む場合:


	$form = new XoopsThemeForm( ... );
	$GLOBALS['xoopsGTicket']->addTicketXoopsFormElement( $form , __LINE__ , 1800 , '(your area name)' ) ;

※XoopsForm自体、利用は非推奨です。


●プレーンHTMLに埋め込む場合:

	$xoopsGTicket->getTicketHtml( __LINE__ , 1800 , '(your area name)' )



●フォーム処理側

	if ( ! $xoopsGTicket->check( true , '(your area name)' ) ) {
		redirect_header(XOOPS_URL.'/',3,$xoopsGTicket->getErrors());
	}

このcheck()でチケットエラーが起きた(=再投稿フォームを表示する必要が起きた)場合には、自動的にフォームが表示されます。

もし、あえて再投稿フォームを禁止したい場合にのみ、以下のように第3引数を指定してください。

	if ( ! $xoopsGTicket->check( true , '(your area name)' , false ) ) {
		redirect_header(XOOPS_URL.'/',3,$xoopsGTicket->getErrors());
	}


※注意: gticket2を使う場合、Xoopsコアが提供するチケットによるチェックは行わないでください。基本的に意味がありませんし、せっかくの再投稿フォームがまったく機能しなくなります。

このgticket2は、現時点ではblocksadminモジュールにだけ実装してあります。しばらく様子を見て、問題がないようなら、他のモジュールについても順次入れ替えていきます。

もし、TinyD+SPAWでInvalid Sessionが頻出するなど、チケットエラーに悩まされているようでしたら、blocksadmin内のinclude/gtickets.php (gticket2) を、対象モジュール(tinyd0等)内のinclude/gtickets.php (gticket1) と入れ替えてください。劇的に改善されるかもしれません。

----------
2006/5/6 fixed typo (thx gusagi!)

Printer friendly page Send this story to a friend

Comments list

GIJOE  Posted on 2006/5/13 6:33
Quote:
今考えているのも、header.phpは読み込まずに、XOOPSブロックはすべて非表示でブロックロジックも実行しない。
使用テーマはdefault決め打ちってというように、極力シンプルに使用とはしてましたけど・・・
ケチをつけたみたいになってしまってすみません。
ただ、テーマをdefaultで決めうちにするくらいなら、直出力の方が良いかと。
このあたり、例の有名なテーマがdefaultであることの特殊な事情(テンプレートが破壊されるあれ)が、今後、修正されるかどうかにもよりますが。

Quote:
あと、'No ticket found'や’Invalid area or referer’の場合には、再投稿無くても良いような気がしますが・・・・
それが、意外にも、No ticket found あたりでエラーになっているケースが多いようなんですよ。何が原因なのか、私にもさっぱり判らないのですが、SPAWとの相性が特に悪いようです。

SPAWあたりだと、フォーム要素とかをJavaScriptでいじったりするんですかね?

ともあれ、CSRF対策は、「本人の意志」を確認できさえすれば良いので、エラーの種類によらず、再投稿フォームを表示する、というのが良いと思ってます。

むしろ、攻撃を喰らった場合でも、「攻撃者が何をさせようと企んでいたのか」が表示されて便利かも
nobunobu  Posted on 2006/5/11 10:54 | Last modified
Quote:
ただ、個人的には、再投稿フォームは、fallback中のfallbackなので、なるべく余計な処理が挟まらないようにした方が良いと思っています。
セキュリティ向上のためのチケットクラスが、余計な脆弱性を持ち込んだのでは本末転倒ですから。
確かにその通りですね。
今考えているのも、header.phpは読み込まずに、XOOPSブロックはすべて非表示でブロックロジックも実行しない。
使用テーマはdefault決め打ちってというように、極力シンプルに使用とはしてましたけど・・・
もう少し考えてみます。

あと、'No ticket found'や’Invalid area or referer’の場合には、再投稿無くても良いような気がしますが・・・・
GIJOE  Posted on 2006/5/11 5:05 | Last modified
nobunobuさん、こんにちは。
Quote:
但し、WordPressは管理機能が表画面にあるので、再投稿フォームをテーマ内に表示するようにしています。
それは素晴らしいですね。

ただ、個人的には、再投稿フォームは、fallback中のfallbackなので、なるべく余計な処理が挟まらないようにした方が良いと思っています。
セキュリティ向上のためのチケットクラスが、余計な脆弱性を持ち込んだのでは本末転倒ですから。
テーマを表示する、ってことは、それなりにいろいろな処理が入るわけで、そこにXSSがあったらわざわざXSS+CSRFという強力なコンビネーション攻撃用の踏み台を用意してしまうことになりかねませんよね。

チケットなんて、XSSがあったら簡単に抜かれますから。
nobunobu  Posted on 2006/5/11 0:28
エラー時の再投稿機能、良いですね!
早速WordPressもgticketベースからgticket2ベースに改変中です。
但し、WordPressは管理機能が表画面にあるので、再投稿フォームをテーマ内に表示するようにしています。
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!