eForm で画像認証を使いたい

こんばんわ。
こちらでもpreg_match_all()に関して調べたのですが、やっぱり有力な情報は得られずです :’(
パターン部分の括弧の数があってないというエラーとは思うのですが、パターン部分は固定値なのでエラーになるならどのサーバ上でも発生する気が・・・。
可能性として考えられるのはプラグインとしてDBに登録されたときに変なエスケープが働いてソースが壊れたくらいですね。
MODxに保存したsslSwitcherと手元のsslSwitcher元ソースでdiffをとってみたらどうでしょうか?
あとphpmyadminとうで直接DBの中を覗いて見るのも手かもしれません。

これで異常なしでしたら、現状お手上げになってしまいます(T_T)

それとサーバ自体の挙動も変ですね。
coredumpをサポートに投げて調べさせてはどうでしょうか?
少なくともphpソースに異常があってもphp本体がエラーとしてphpソースの実行を終了させるのが通常の流れで、coreを吐いて自分(php本体)も落ちてしまうというのは問題だと思います。
が、サポートの反応が悪いんですかぁ(--;

話しがそれますがcoreが吐かれる原因を探すのは結構大変なんですよね。。。
アプリケーションの相性だったり、ドライバに問題があったり、メモリやHDDの物理的な障害だったり。
あとは単なるバグだったりです :’(

プラグインの設定画面で文字化けもないんだし DB が壊れているはずがないだろうと思っていましたが念のため確認してみました。
modx_site_plugins というテーブルで plugincode というフィールド自体には何の問題も有りませんでしたが moduleguid というフィールドに 化け文字 � が入っています。それを一度 phpmyadmin で消した後 HPを表示してみましたが状況に変わりはありません。

実際には modx でプラグインコードを保存するタイミングで � が入ってしまうようです。最初からインストールされているプラグインにはこのような文字化けコードは入ってないんですがスニペットでも同じで modx で保存をするとこのコードが入ってしまいます。たぶんここに見えている文字化けコードは最終的な結果でそれ以外の動作にも影響を与えている可能性は大です。

先日の問い合わせで「PHPのセキュリティーシステムの関係でサーバーが停止していた」という回答を技術者の人から直接返信をもらいましたが server19 まで進めた時点でまだそんな状況が残っていること自体心配な点です。当初は昨年10月中にすべてのサーバーをアップグレードする予定だったものが server19 の時点で2月までずれ込んでいるということ自体がその辺の問題を未解決のまま次々と次のサーバーのアップグレードと進めていった結果まともに動いているサーバー自体ないのではないでしょうか。

2月の中旬以降はサーバーが停止することはなくなっていますがこういったところに影響が出ているということは初めて認識したしだいです。現在問題が表面化せず動いている PHPアプリも非常に心配な状況です。コードを書き換えた時点で同じ状況になってしまわないかということです。

現在は modx のみですがこの状況を説明するには joes の技術担当に同じ環境をつくってもらって再現してもらう以外説明が難しいと思います。対応の悪い joes がそこまでやってくれるとも思えません。前回も最初の問い合わせには回答もなく、2回目で少し強めに対応を求めたところようやく返事が来たという状況で返事ももらうまでに１週間かかっています。

したがってこのことにこれ以上時間をかけるのはこちらとしても不本意ですし、移転を考えている理由です。
じつは、zipを解凍してからFTPで送ってからの modx インストール自体も最後の[完了]が出ないため、現在は zip のまま送りサーバー上で unzip をかけないと正常にインストールも完了できない状態です。 :’(

さくらレンタルサーバの共有SSLについて

4/23 日に質問をして5日目に返信がどうなっているのか問い合わせたところ「最優先で対応させていただきます」との回答をもらっていたのですが本日19:00頃になってようやく、こんな回答が帰ってきました。いつも〇〇という人から回答を頂くのですが一回目の回答はいつも肝心なところをはずしたような回答しかもらえません。プロクシ情報を取得するためのHTTP_VIA に関してもう一度質問をたった今、再送信しました。

OSのバージョンアップ後問い合わせが多いということで回答が遅いのは我慢していたのですが一回目の回答で要領を得ない内容しかもらえないので手間のかかりすぎです。

同じような質問が他の人からも寄せられていれば機械的にすぐに回答があったと思うのですがだれもこの件に関しては質問していないんでしょうか。ほかにさくらを使っている人からもどんどん質問メールを出してほしいと思っています。

お問い合わせいただき誠にありがとうございます。
さくらインターネット カスタマーセンターの〇〇と申します。

> ■質問内容
> ----------------------------------------------------------
> 件名：共有SSLの利用方法について
> ----------------------------------------------------------
> $_SERVER[’HTTPS_HOST’]
> $_SERVER[’HTTPS’]
> $_SERVER[’HTTP_VIA]
>
> 上記のいずれかの方法で現在SSLの状態にあるのかどうかを判断したいのですがどの環境変数にも値がセットされないため利用方法でつまずいています。
>
> 上記以外の有効な判断方法があれば教えてください。


この度は返信が遅れておりご迷惑をお掛けしております。

せっかくお問い合わせいただいたところ申し訳ございませんが
「さくらのレンタルサーバ」の共有SSL機能は、プロクシとして動作するよう設
定しており、ウェブサーバから環境変数を取得することができない仕様となって
おります。予めご了承ください。

以上、よろしくお願いいたします。
今後ともさくらインターネットをよろしくお願いいたします。

いくらなんでもここでさくらの担当者の名前を出すのはどうかと思いますし、その対応をここで書く必要はないと思います。

ちなみに簡単な実験してみれば分かることだと思いますが、HTTPSの共有SSLのURLでアクセスした場合は、HTTP_X_FORWARDED_FORが出てくるようです。
まあ、これも出力されなくなったらHTTPかHTTPSかはPHPからは不明になりますが、当面はこの有無で判定はできるんじゃないでしょうか？

ZeRoさん、久々の登場でのアドバイスありがとうございます。

さっそく試してみたところ HTTP_X_FORWARDED_FOR で判断できそうです。

結果として共有SSLのプロクシを通した結果の環境変数は下のような結果となりました。
[table]
[tr][td][/td][td]HTTP_VIA　[/td][td]HTTP_X_FORWARDED_FOR[/td][/tr]
[tr][td]coreserver　[/td][td]〇　[/td][td]〇[/td][/tr]
[tr][td]sakura　[/td][td]×　[/td][td]〇[/td][/tr]
[tr][td]joes　[/td][td]×　[/td][td]×[/td][/tr]
[/table]
JOESの場合どうにもならないようですが、さくらではHTTP_VIA にアクセス元のプロキシサーバ名が判断できないのは片手落ちとしか思えません。共有SSLのプロクシなのか速度アップ用のプロクシなのかスパム用なのかが判断できないんですよね。このあたりダメかもしれませんが、SSLとは別案件としてさくらへ要望として出したいと思います。

HTTP_VIA は正式な環境変数ではないようなことを聞いたことがあるので さくらのFreeBSD とcoreserver の linux の違いでこういった問題はどうにもならないことなんでしょうか？

ありがとうございました。

確かに、HTTP_X_FORWARDED_FORだけで判断するのは確実性にかけますね。
ここらあたりはどういう仕組みで行うかによるのでなんともいえないところです。
そもそも共有SSLなんていう仕組み自体が苦肉の策みたいなもんですから･･･。

いずれにしても共有SSLの場合は、もう一捻り　環境変数以外の手立てで考える必要があるかも知れませんね。
機密性の高い情報をやり取りするならば、別のサービスとか独自SSLとかにした方が無難でしょう

sslSwitcher 使用記 - 中間報告

HTTP_VIAの有無だけの判定では匿名、非匿名プロキシからのアクセスではSSLに切り替えることができなかったのでプロキシサーバー名を確認することで共有SSLサーバの判定方法の確実性をあげました。最終段がSSLプロキシの場合、多段プロキシ接続にはならないようです。

（１）coreserver および xrea の場合
　　共有SSLはcoreserver から xrea の共有SSLを使うことも可能なようです。
　　すべての共有サーバに対して同じ共有SSLサーバが使用されるため外部のプロキシサーバとなります。

（２）sakuraの場合
　　sakura では外部のプロキシからアクセスされた場合は HTTP_VIA がセットされ共有SSLの場合のみセットされません。
　　レンタルしている共有サーバーごとに共有SSLがセットされます。したがって外部のプロキシではありません。

（３）joes の場合
　　Joesに関してはプロキシタイプではなく共有SSLを使った場合にも HTTPS が on になるので判定は不要なようです。

HTTP_VIA に関するさくらインターネットからの回答

「HTTP_VIA が取得できないのはSSLプロキシの制限ではなくWebアプリケーションファイアウォールによるものでした」という訂正の回答を頂きました。

ということはWebアプリケーションファイアウォールをユーザが意識して設定しなくても何種類かのファイアウォールがかけられているということのようでどういった制限がかかっていて modx に限らずwebアプリケーションにどのように影響してくるのか Joesの場合も含めてユーザはまったく予測できないことにあるようです。

このスレッドも早々にsslSwitcher の動作確認を済ませて近々にクローズできればとは思っているしだいです。

Joes で preg_match_all() がエラーになっていた原因について

2月以前にインストールしていた modx ではエラーにならずに新規で modx をインストールしたものが preg_match_all() でパースエラーになってしまうということは以前に話したととおりですが、その結果どのような状況になっていたかが状況が安定した最近になってわかりましたので報告しておきます。

まずは安定してから modx が core ダンプファイルははかなくなりました。
sslSwitcher は入れない状態でもそのような状況が3ヶ月ほど続いている状況でしたので何かを触るのが怖いような状態だったと思います。

preg_match_all でパースエラーになってしまう直接の原因ですが sslSwitcher ソースコード内の \記号が保存した段階ですべて消失していたようです。preg_match_all と preg_replace内の \がなくなってしまった結果表示されていたエラーメッセージでした。保存段階ではオリジナルからのコピーペーストで保存しているためまったくどこが変わってしまったのかいままで気が付かない状態だったのですがこういうのってかなり怖い現象です。

Joes ではまだ AjaxSearch が動かないという不具合も残っているわけですが、これがインストール段階で WAF の影響を受けているのか実行段階でファイアーウォールにかかっているのかはまったくわかりません。

（３）joes の場合
　　Joes ではフレンドリーurl を使ったときに共有SSLに切り替えると 404 Not Foundになってしまいます。
　　および SSL接続時 base_url が /~ユーザID/フォルダ名/ になってしまうので site_url の設定は
　　下記のようになります。

　　一応ここまで確認できたのであと少し･･･