ALLOWED_HOSTS

Djangoの1.5が出たので、ロクにドキュメントも読まずにアップデートしたら、DEBUG=False の時だけ Internal Server Error が出るようになってしまいました。

DEBUGをTrueにすると現象が出ないので、何が間違っているのか調査のしようがありません。

原因は ALLOWED_HOSTS が宣言されていなかったことでした。

Django-1.4で作成したプロジェクトの settings.py に次の行を追加することで、とりあえず動くようになります。

ALLOWED_HOSTS = [ '*' ]

リリースノートに、ちゃんと書いてあるじゃん！読めよ！みたいな。。。

ALLOWED_HOSTS required in production¶
The new ALLOWED_HOSTS setting validates the request’s Host header and protects against host-poisoning attacks. This setting is now required whenever DEBUG is False, or else django.http.HttpRequest.get_host() will raise SuspiciousOperation. For more details see the full documentation for the new setting.

企業ユースだとセキュリティ的に接続元を限定したくて、Apache の Allow fromを 宣言することが多いのですが、これだと設定ファイルに書けばいいので楽チンですね。オーバーヘッドは気になりますけど・・・。

Wordpressのエラー処理が？？？

個人的には、サイトの作りに注文のほぼ存在しないお客様にはWordpressを、細かく注文をつけてくるお客様にはDjangoもしくは別のミドルウェアを紹介しています。

で、今回はWordpressをご指名で、機能的な調整をしたいという注文が入りました。

調整内容自体は簡単です。単に投稿時の入力内容に文字数制限を付けたいという話です。

でも、すでに地獄の１丁目だったんですね。。。

調べて判ったことですが、そもそもWordpressにはエラーの回復処理が存在していませんでした。
普通の入力フォームだと、入力項目にエラーがあると再度入力画面を表示して、画面の上部とか、エラーの起きた入力項目のそばにメッセージが表示されますよね。
それがWordpressではできないみたいです。

エラーを検出した時はwp_die()を呼び出して、エラーメッセージしか表示されていないページを出して、利用者には戻るボタンで戻ってもらうしかない。ただし、戻った時にはエラーの発生した入力項目は空白になっています。
それがいやなら、JavaScriptでデータのポスト前にチェックを行うか、コアの最深部に手を入れるしかなくなってしまいます。
JavaScriptでの検査は利用者が善人である前提でしか使えませんから、可能な限り回避したいとなると、Wordpressという選択肢自体が危うくなってしまいます。

WordpressにはWP_Errorクラスというのがあります。
フィルター関数内で簡単なチェックを行い、投稿データが保存条件を満たしていないと判断した時点で、このクラスのインスタンスを作成して返す。あとはWordpressまかせ。。。みたいな想像をしていたのですが、実際には何も起きずに、というか壊れた投稿を記録されてしまったため、理由を探してコアの中をさまよった結果判明したことです。(version 3.5.1)

アクションならと思いましたが、こちらも最終的にはフィルターと同じく$wp_filterに格納されて、apply_filters()とかで呼び出されます。アクション関数やフィルター関数からの戻り値は確かに変数に格納されるのですが、実行ループ中にその変数が参照されることはありません。


フィルター内でシステム的にクリティカルな状態になったら、後続のアクションをキャンセルして回復処理を行うとか、そういうプログラマティックな調整は一切受け付けてくれないミドルウェアであるとしたら、ちょっと今後は関わりたくないかも。。。

テーマと権限ロールが最初から設定されているところは良かったんだけどなあ。