エラー時の再投稿機能、良いですね！
早速WordPressもgticketベースからgticket2ベースに改変中です。
但し、WordPressは管理機能が表画面にあるので、再投稿フォームをテーマ内に表示するようにしています。

nobunobuさん、こんにちは。
Quote:それは素晴らしいですね。

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

チケットなんて、XSSがあったら簡単に抜かれますから。

Quote:確かにその通りですね。
今考えているのも、header.phpは読み込まずに、XOOPSブロックはすべて非表示でブロックロジックも実行しない。
使用テーマはdefault決め打ちってというように、極力シンプルに使用とはしてましたけど・・・
もう少し考えてみます。

あと、'No ticket found'や’Invalid area or referer’の場合には、再投稿無くても良いような気がしますが・・・・

Quote:ケチをつけたみたいになってしまってすみません。
ただ、テーマをdefaultで決めうちにするくらいなら、直出力の方が良いかと。
このあたり、例の有名なテーマがdefaultであることの特殊な事情（テンプレートが破壊されるあれ）が、今後、修正されるかどうかにもよりますが。

Quote:それが、意外にも、No ticket found あたりでエラーになっているケースが多いようなんですよ。何が原因なのか、私にもさっぱり判らないのですが、SPAWとの相性が特に悪いようです。

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

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

むしろ、攻撃を喰らった場合でも、「攻撃者が何をさせようと企んでいたのか」が表示されて便利かも