PEAK XOOPS - gticket2 released 
XOOPS
XOOPS : gticket2 released
A ticket/token class named XoopsGTicket is updated.
In the version named gticket2, repost form will be opened if ticket error occurrs.
This feature must reduce user's stresses.
The usage of gticket2 is almost the same as gticket.
- include_once include/gtickets.php
- add hidden into your form
- add check() into your transaction
form side with XoopsForm:
$form = new XoopsThemeForm( ... );
$GLOBALS['xoopsGTicket']->addTicketXoopsFormElement( $form , __LINE__ , 1800 , '(your area name)' ) ;
form side with plain HTML:
$xoopsGTicket->getTicketHtml( __LINE__ , 1800 , '(your area name)' )
transaction side:
if ( ! $xoopsGTicket->check( true , '(your area name)' ) ) {
redirect_header(XOOPS_URL.'/',3,$xoopsGTicket->getErrors());
}
If an error occurs in cheking the ticket, "repost form" is displayed automatically.
If you don't want to display "repost form", call check() like this.
if ( ! $xoopsGTicket->check( true , '(your area name)' , false ) ) {
redirect_header(XOOPS_URL.'/',3,$xoopsGTicket->getErrors());
}
You can check the behaviors and usages of gticket2 by downloading the latest blocksadmin module.
note: Don't check doublly by XoopsSecurity::check() even if you use XoopsForm.
If you call core's check() also, the system of repost can't work.
----------
2006/5/6 fixed typo (thx gusagi!)
Comments list
GIJOE
Posted on 2006/5/13 6:33
Quote:ケチをつけたみたいになってしまってすみません。
ただ、テーマをdefaultで決めうちにするくらいなら、直出力の方が良いかと。
このあたり、例の有名なテーマがdefaultであることの特殊な事情（テンプレートが破壊されるあれ）が、今後、修正されるかどうかにもよりますが。
Quote:それが、意外にも、No ticket found あたりでエラーになっているケースが多いようなんですよ。何が原因なのか、私にもさっぱり判らないのですが、SPAWとの相性が特に悪いようです。
SPAWあたりだと、フォーム要素とかをJavaScriptでいじったりするんですかね？
ともあれ、CSRF対策は、「本人の意志」を確認できさえすれば良いので、エラーの種類によらず、再投稿フォームを表示する、というのが良いと思ってます。
むしろ、攻撃を喰らった場合でも、「攻撃者が何をさせようと企んでいたのか」が表示されて便利かも
今考えているのも、header.phpは読み込まずに、XOOPSブロックはすべて非表示でブロックロジックも実行しない。
使用テーマはdefault決め打ちってというように、極力シンプルに使用とはしてましたけど・・・
ただ、テーマをdefaultで決めうちにするくらいなら、直出力の方が良いかと。
このあたり、例の有名なテーマがdefaultであることの特殊な事情（テンプレートが破壊されるあれ）が、今後、修正されるかどうかにもよりますが。
Quote:
あと、'No ticket found'や’Invalid area or referer’の場合には、再投稿無くても良いような気がしますが・・・・
SPAWあたりだと、フォーム要素とかをJavaScriptでいじったりするんですかね？
ともあれ、CSRF対策は、「本人の意志」を確認できさえすれば良いので、エラーの種類によらず、再投稿フォームを表示する、というのが良いと思ってます。
むしろ、攻撃を喰らった場合でも、「攻撃者が何をさせようと企んでいたのか」が表示されて便利かも
nobunobu
Posted on 2006/5/11 10:54 | Last modified
Quote:確かにその通りですね。
今考えているのも、header.phpは読み込まずに、XOOPSブロックはすべて非表示でブロックロジックも実行しない。
使用テーマはdefault決め打ちってというように、極力シンプルに使用とはしてましたけど・・・
もう少し考えてみます。
あと、'No ticket found'や’Invalid area or referer’の場合には、再投稿無くても良いような気がしますが・・・・
ただ、個人的には、再投稿フォームは、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:それは素晴らしいですね。
ただ、個人的には、再投稿フォームは、fallback中のfallbackなので、なるべく余計な処理が挟まらないようにした方が良いと思っています。
セキュリティ向上のためのチケットクラスが、余計な脆弱性を持ち込んだのでは本末転倒ですから。
テーマを表示する、ってことは、それなりにいろいろな処理が入るわけで、そこにXSSがあったらわざわざXSS+CSRFという強力なコンビネーション攻撃用の踏み台を用意してしまうことになりかねませんよね。
チケットなんて、XSSがあったら簡単に抜かれますから。
Quote:
但し、WordPressは管理機能が表画面にあるので、再投稿フォームをテーマ内に表示するようにしています。
ただ、個人的には、再投稿フォームは、fallback中のfallbackなので、なるべく余計な処理が挟まらないようにした方が良いと思っています。
セキュリティ向上のためのチケットクラスが、余計な脆弱性を持ち込んだのでは本末転倒ですから。
テーマを表示する、ってことは、それなりにいろいろな処理が入るわけで、そこにXSSがあったらわざわざXSS+CSRFという強力なコンビネーション攻撃用の踏み台を用意してしまうことになりかねませんよね。
チケットなんて、XSSがあったら簡単に抜かれますから。
nobunobu
Posted on 2006/5/11 0:28
エラー時の再投稿機能、良いですね！
早速WordPressもgticketベースからgticket2ベースに改変中です。
但し、WordPressは管理機能が表画面にあるので、再投稿フォームをテーマ内に表示するようにしています。
早速WordPressもgticketベースからgticket2ベースに改変中です。
但し、WordPressは管理機能が表画面にあるので、再投稿フォームをテーマ内に表示するようにしています。
Login