今日現在、ｅラーニングモジュールXoopsHP1.05は以下のXoopsで実証済みです。

Xoops2.0.12J
Xoops2.0.13J
Xoops2.0.13aJ

なおXoops2.0.11以前（2.0.11を含む）は、Xoops本体側のサニタイザ関連処理が変更されていますので、また[bb]コードや[html]コードによるクロスサイトスクリプティング（Internet Explorerのみ）によるセキュリティ脆弱性の対策を兼ねて、公式サイトでも報告されているように、Xoops2.0.13a-Jへのアップデートをお勧めします。

MAILPARK事務局（サーバー管理センター）

---

コミュネス運営事務局

MAILPARKさん、こんばんは。先日はありがとうございました。前スレでアドバイスをいただいたあと、いろいろサーバーの設定を見直してみました。いまのところ、XoopsHPのPOST送信を阻害するような箇所は発見に至っておりません。XOOPSシステムのバージョンアップは、モジュールの動作不良をおこす可能性があるので、ちょっと抵抗があるのですが…バックアップをとった後、勇気を出してやってみます！

今後ともご指導のほどをよろしくおねがい申し上げます。

自己レスです。

バーチャルホストをひとつ準備し、Xoops本体（2.0.13a JP）を新規にインストールして動作確認してみたのですが、おなじ結果でした…。あと考えられるのは、Apcheのバージョンの違い（1.3系と2.0系）による細かな仕様の違いでしょうか。こっちのほうはバーチャルホストでどうにか出来る問題でないので、困ってます…。もうちょっと悩んでみます。

改めてココにも書いておきます。
わたしの環境は

Xoops本体 2.0.13a JP
XoopsHP 1.05
MySQL 3.23.58
Apache/2.0.52　→ 2.0.53 （今日更新しました）
PHP 4.3.11

です。

いろいろ実証テストを頂きありがとうございます。
Apache2.x系の問題か、それともApacheで時々利用する（こともある）レイアウト追加モジュール「mod_layout」系の問題なのかとも想像しています。

ただ、mod_layoutによる悪影響は、なんでもかんでも構わずHEADER,FOOTERにHTMLなどを埋め込んでくれますので、問題ファイルのHTML制御が完全に崩れてしまい、問題ファイルのソースがそのまま表示される（JavaScriptやHTMLタグが本来あるべき形の正常に表示されない）という問題を確認しています。
‥‥というか、mod_layoutは、激安レンサバや無料レンサバで、サイトの上下のHeaderやFooterに、強制的にバナーのリンクやフラッシュ広告を差込む目的に用いられており、XoopsHPに限らず、HTMLを利用するタイプの「サイト構成」では、ほとんど正常にHeaderに仕込んだJavaScriptが破壊される、という症状に見舞われますね。（余談ですが、そういう場合は外部スクリプトロードで対処するしかないですが、そうなると、最悪の場合は２重に無料レンサバの広告だらけ、になったりします。）

今回の件は、正常にポップアップウインドウから後のPOST処理の部分ですので、しかもサーバー上で直接にアクセスしても同様、ということで、サーバーの内部による単独問題（通信は関係ない）と絞り込んでよろしいかと思われます。

サーバー内部で、例えばサーバー本体に設定されたFirewallあたりもチェックしてみると良いかも知れません。ただ一部のFirefoxや旧Safariなどではリファラを吐かないので、ホワイトバックのままで、ずーーーっと止まってます。（リファラを吐かないブラウザでは、Xoops本来のセキュリティ仕様によって、そこから先の処理が止まります。これは、例えば「成績だけを改ざんページから強制POSTしてデータを記録させる」などから守られるようになっていますが、その解析の識別にリファラチェックが用いられている、ということで、この辺の技術テキストは、同梱のパッケージモジュールに詳しく書いてありますので、ご参照ください。）

サーバー内部のFirewallとは、サーバー上層部で処理されるブラウザからの、サーバー内部でのセキュリテイの問題です。
サーバー上でのブラウザでのアクセスでもダメ、という場合に考えられる、もうひとつの問題です。もうひとつとは、Apacheなどの内部的なPOST処理（サーバー環境設定）の他の問題です。

サーバーは、上層部（表層処理）のlocalhostに対して、内部でglobal処理するようになっていると思います。インターフェース（ファーマシー）で処理したものは、いきなりglobal処理されず、localhostで処理されることが多いです。127.0.0.1ですね。
このlocalhost（127.0.0.1）で処理されたブラウザ結果を、global内部処理（210.111.222.xxx：あなたのサーバWAN-IP）で通過させる際にも、サーバーサイドFirewallは「有効」になります。
ここに「リファラを禁止」「ローカルIPからのPOST禁止」などが有効になっていると、サーバー上で直接ブラウザ越しにXoopsHPをアクセスしても、結果が同じ、ということになります。
ローカルは、しばしば「なりすまし」スマーフィング攻撃の対象として、ブロックしているサーバー設定を見かけます。
127.0.0.1
192.168.x.x
10.0.x.x
などを無効化するように設定していることがありますので、これを「きれいに開放」してやることも大切です。きれいに開放、とは、MACアドレスを識別信号として併用させたり、時間的に開放ゲートを開いたり、またリバースドメインで解析してやる、などの方法で、明らかに「そのローカルは自分そのもの」というように「きれいに開放」してあげましょう。

てっとりばやく、内部Firewallを一時的に「停止」して、ブラウザ越しにXoopsHPをアクセスしてみると、サーバーの環境設定による問題なのか、サーバーサイドFirewallの問題なのか、切り分けることができると思います。

あとは、Apache1.x系のレンサバで実験してみるのも手ですね。
Apache2.x系のmod_lauoutモジュールを有効にしている場合は、ソースがベタで表示される（問題ファイルHTMLが崩れる）のですが、今回はこれは関係無いでしょう。

あと、ブラウザの環境設定で、リファラの送信を行うようになっているかチェックするのも必要ですね。いちおう基本的にWinXP-InternetExplorerとMAC-OSX Tiger10.4.2 Safariでのリファラ処理に対応するように作ってありますので、他のブラウザは今後の課題と考えています。（もっとも、もともとリファラを吐かないブラウザは、今後の課題に含めていません‥‥）

---

コミュネス運営事務局