page_adsence

2010年9月14日火曜日

doctrineで生成するschema.ymlに関して

symfonyのタスクでデータベース上に保存されているデータをfixture形式でダンプを取ってくれるタスクがあり、
それを実行してみた。

symfony doctrine:data-dump

すると、
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'v.id' ~
v.idってカラムがないらしい。
そもそもidなんてカラム作ってないのになんでこんなことになってるんだと思って調べてみたら、
エラーが出たのはViewの部分の記述だった。
そこで、schema.ymlを見てみた。
中を見てみると

VHoge:
  connection: doctrine
  tableName: v_hoge
  columns:
    id:
      type: integer(8)
      autoincrement: true
      primary: true
    fuga_id:
      type: integer(4)
      fixed: false
      unsigned: true
      primary: true
      default: '0'
      notnull: true
      autoincrement: false
idってカラムがありました・・・。
なんでこんなカラムが追加されてるんだと思いながらも、削除してみた。
モデルも再生成して、もっかい実行。
同じエラーが・・・。
カラムは削除したはずなのになーと思いながらも、primaryがtrueになっているカラムがないといけないのではないかと思い、fuga_idのprimaryをtrueにして、モデルを再生成して実行してみたら成功しました。

どうやらschema.ymlには必ずprimaryがtrueになっているカラムが1つないとエラーになるみたいです。
あとでソースを追って、ちゃんとした原因を突き止めよう。

2010年9月9日木曜日

iphone4のケースが来た。

思ったよりだいぶ早かった。
到着予定日が10月1日だったのに、今日届いた。
iphone4の時もこのくらい早ければよかったのに…。

ケース自体はまぁまぁいい感じかも。
背面はプラスティックで、側面がシリコンになってる。
結構しっかり作りで以外だった。
今回頼んだケースは黒なんで、気分によって付け替えるとしよう。
とりあえずしばらくはこのケースを使ってみようと思います。

2010年9月8日水曜日

mb_strlenがUndefined function

フォームで入力された文字数チェックしようと思ってmb_strlenを使ったら、Undefined functionって出てきた。
あれっと思ってphpinfo見てみたら…。

ない!!

php-mbstringがインストールされてませんでした…。
最初の段階でちゃんとチェックしておかないと、後々面倒ですね。
yumからサクっとインストールして解決しました。

2010年9月5日日曜日

php.iniのX-Powered-Byについて

HTTPヘッダに付加されているX-Powered-By。
これにPHPのバージョンが表示されている。
セキュリティ面を考えると、サービスイン後のこういった表示は控えるべきだと思われる。
ってことで、その表示を出さないようにする方法は以下のとおり。

php.iniを以下のように書き換えてやればよい。

expose_php = On → Off

で、書き換え後に保存して、Webサーバーを再起動させる。
以上で完了。

2010年9月3日金曜日

symfonyのセキュリティの設定に関して

最近ちょくちょくsymfonyを触るようになってきたので、一度セキュリティに関して調べてみた。
今回気になったのは下記の記事。

http://blog.symfony.jp/2009/03/05/178

この記事ではsf_charsetがUTF-8で、なおかつescaping_methodをESC_ENTITIESにすると問題があるというものです。
古いバージョンのsymfonyではデフォルトがESC_ENTITIESになっていましたが、
1.2以降のsymfonyではデフォルト値がESC_SPECIALCHARSに書き換えられているようですので、
自分で意図的に変更しない限りはトラブルに見舞われることはないと思われますが、一応念のため記事にしておくことにしました。

symfonyでは標準でHTML出力のエスケープ処理が組み込まれており、テンプレートにスカラ、配列、オブジェクトのメソッド呼び出しの結果など、あらゆる値がエスケープされるようになっています。
そのエスケープメソッドがhtmlentitiesであると問題が発生するよということ。
このhtmlentitiesですが、マルチバイトでなければ何の問題もありませんが、
マルチバイトでUTF-8の文字コードの場合に未定義の文字参照が生成されてしまうおそれがあります。
こちらのブログでは「∵」(U+2235)がその該当の文字だということで、取り上げられています。

symfony1.4ではescaping_strategyはデフォルトtrue、escaping_methodもESC_SPECIALCHARSとなっているので、
特に心配する必要はありません。
とはいえ、古いsymfonyを使っている案件の更新とか、途中からアサインされた場合に設定がESC_ENTITIESになっている可能性が0ではないので、一応覚えておこうと思う。

・リファレンス
http://www.symfony-project.org/reference/1_4/ja/04-Settings#chapter_04_sub_escaping_strategy