ロリポで運営してきたmikimarche.comに使用中のNucleusというCMS(コンテンツ管理ソフトウェア)が挙動不審になる件で、内容の引越とシステム変更作業を進めていることは先日から何度か書いている。結論も今後の方針も変わらないのだが、原因がようやく特定されたので、備忘録として書いておきたい。
これまでわたしが漠然と感じてきたことは、mikimarche.comでは、ソフトの内部設定がロリポップで借りている場所の絶対パス(/Users/なんちゃらかんちゃらの文字列)になっているのに、呼び出している場所が自分が取得したドメインなので、別サイト内からスクリプトが呼び出しを受けていると勘違いをしたロリポップにより、一部の動作がブロックされるようになった(クロスサイトスクリプティングの禁止に引っかかっている)のだろうというものだった。だがそのロリポの設定が、以前はできていた投稿でエラー頻発を実感するようになるまでの10日間程度のあいだになぜ急に厳しくなったのかという案内が見当たらなかったため、確信が持てなかった。そのため、使用しているソフトNucleusが古すぎるせいも多少はあるのだろうと、引越作業を進めてきた。
だが、今後のために実験していた最近のソフトウェアでも、同じような403エラーが出た。そこでロリポップの403エラーで検索をかけたところ、WAFを切ってしまえば動くと書いてあるサイトを発見した。
クロスサイトスクリプティングをブロックするWAFは、わたしがエラーに困るようになる以前から、ロリポップでは導入されていたように思う。なぜ先日から急に厳しくなったのかは、やはりわからない。だが、最近のソフトでも同じ403が出るということは、今後はWAFを切ってしまうか、あるいはそれに引っかからないようなソフトをインストールするしかない。
ちなみにわたしが実験していたCMSは、インストールするディレクトリと、公開表示されるディレクトリの場所が違う。動作を管理するURLの場所が利用者に特定されにくいほうがセキュリティとしてよいのだろうが、それがロリポのWAFに引っかかり、ブロック対象になるのだろう。今回はたまたま今後のソフトの実験段階で気づいたことではあるが、もし今後いずれかのCMSを気に入り、正式に使うことになったとしても、同じ問題が起こる。ソフトを呼び出す場所がmikimarche.comで、設置場所のconfigがロリポップレンタルサーバ内の絶対パスで書かれていれば、仮に実験段階でうまく動いたとしても、やはりWAFに引っかかる可能性が高いと思う。
現在このブログはロリポップ内にあるが、WordPressでそのエラーが出ないのは、ロリポップで借りている場所のままの設定で利用し、別階層にスクリプトをおいているわけではないからだろう。ひとつの改装で完結していて、クロスサイトスクリプティングではないからだ。もし長年親しんだこのブログを、呼び出しだけ別ドメインからという設定にしたら、おそらく動作が安定しなくなる。
もう少し実験してみて、WAFを切ったほうがいいのかなという話になるかもしれない。さて、どうしたものか。