53件中 31-35件目     [ ... 2 3 4 5 6 7 8 9 10 11 ]

PHPには、関数名を引数に取る関数がいくつかあるが、クラスのメソッドを渡すこともできる。 クラスの静的(static)なメソッドを渡したい場合には、関数名を文字列で渡していたところに、array(クラス名, 静的メソッド名)を渡すとうまくいく。

例えば、call_user_func関数では以下のようにする。

<?php
class MyClass {
	static public function ClassMethod(){
		echo '静的メソッド';
	}
}

call_user_func(array('MyClass', 'ClassMethod'));
?>

オブジェクトのメソッドを渡したい場合には、array(オブジェクト, メソッド名)で渡すとうまくいく。

<?php
class MyClass {
	private $var;
	public function __construct($str){
		$this->var = $str;
	}
	public function ClassMethod(){
		echo $this->var.'オブジェクトメソッド';
	}
}

$obj = new MyClass('test');
call_user_func(array($obj, 'ClassMethod'));
?>

このように関数名の変わりにクラスのメソッドが渡せるのはcall_user_func関数だけでなく、usort関数array_walk関数array_map関数などでも同様に渡すことができる。 静的メソッドであればcall_user_func('MyClass::ClassMethod')のような方法でも渡すことができそうな気はするが、残念ながらそれはできない。


PHPで開発してるときに、ふと「リダイレクトは絶対URLで書かなきゃいけないんだったかな?」と思った。 相対パスでもたいていのブラウザは動くが、動かないのもあるだろうし、相対パスの場合と絶対URLの場合を逆に覚えていたらめんどうなことになるので調べてみた。

最後の1つだけ違うが、それ以外は絶対URL推奨という話。 古いブラウザが中心になるようだが、意外と相対パスのリダイレクトに対応していないものが多い。 絶対URLで書くのが正しいようだし、基本的には絶対URLで書き、もし絶対パスがダメな場合があるようであれば、ユーザエージェントなどにより場合分けするのが良さそうだ。
相対パスでなければならないというのは上記のau+SSLのケースしか見つからなかったが、もしかして「モバイルWeb開発に失敗しない鉄則」 - @ITの「絶対URLでリダイレクトを行う際の注意」のような特殊な状況が原因だったりしないだろうか? これがなければ、全て絶対URLでも良さそうなのだが・・・。


JavaScriptでPHPのhtmlspecialchars関数と同じ動作をする関数がないか探していたところ、それとは関係ない記事だが「htmlspecialchars/htmlentitiesの正しい使い方」という記事を見つけた。

htmlspecialcharsとhtmlenties関数はENT_QUOTESを指定しないとENT_COMPAT(セキュリティ上問題があるが互換性を維持)が指定された状態と同じ動作をします。

な・・・・・なんだってーーー!?

htmlspecialchars関数使いまくってるのに・・・・・修正箇所多すぎw

オレ\(^o^)/オワタ



・・・・・・と思ったが、どうやらシングルクォートを変換しないだけのようなので、ダブルクォートで囲まれている部分なら問題ないようだ。 HTMLタグの属性値は全てダブルクォートで囲ってるし、JavaScriptの一部が心配なくらいだ。 それでも文字エンコーディングの指定をしていない問題はあるから、重要なプログラムだけでも書き換えようとは思う。

そういえば、マニュアルに

ENT_QUOTES が設定されている場合のみ、 ''' (シングルクオート) は '&#039;'になります。
なんて書いてあったのを見た気がする・・・。

当時はPHPを覚えたばかりで意味を理解できず、第2引数なしで今まで使い続けてた・・・。

orz


普段、PHPである程度大きなものを作る場合、E_NOTICEなど初期設定では出力されないエラーを含め、全てのエラーを出力するようにして開発するのだが、今作ってるものではうっかり設定するのを忘れていた。 それを思い出し、全てのエラーを出力するように変更したところ何故かdate関数でE_STRICTのエラーが出ていた。

Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead

今までそんなエラーはでなかった気がしたが、調べてみるとPHP 5.1.0以降ではそうなってるらしい。 マニュアルを見ると日付関数には以下のような注意書きがあった。

注意: PHP 5.1.0 以降(日付/時刻 関数が書き直されてから)、タイムゾーンを 正しく設定せずに日付/時刻関数をコールすると E_NOTICE が発生し、またシステムの設定や TZ 環境変数を 使用すると E_STRICT が発生するようになりました。

E_NOTICEじゃなくて、E_STRICTが出力されているのは、システムの設定を使ってるからだろうか。 TZ 環境変数を使うとE_STRICTが発生すると書いてあるのに、以下のように書いて、エラーが出力されなくなるのは何故だろう?

putenv('TZ=Asia/Tokyo');

とりあえず、date_default_timezone_set関数でやっておけば大丈夫そうな気がするので

date_default_timezone_set('Asia/Tokyo');
と書くか、php.iniで
date.timezone = Asia/Tokyo
と書くか考えたが、後者の方が楽なのでそちらを選択した。

前者でも共通で読み込むファイルに書けばすむのだが、全てのプロジェクトでやるのもめんどうだと判断した。


会員制の掲示板のように、ユーザが登録し利用するWebサービスを提供する場合、認証のためにユーザのパスワードを保存・管理することが多い。 このとき、パスワードを平文で保存(暗号化などをせずにそのまま保存)していると、管理者や開発者などにはパスワードを見ることができてしまう。 管理者や開発者に悪用する気がなかったとしても、パスワードの漏洩などにより誰かに悪用されてしまう危険性がある。

その対策として、パスワードを暗号化するという手もあるが、復号されてしまう危険性もある。 そこで、パスワードをmd5sha1のような不可逆な変換(変換したものから元に戻せない変換)をして保存する。
認証のときには、「md5(sha1)で変換して保存したパスワード」と「入力されたパスワードをmd5(sha1)で変換したもの」を比較して一致するか調べる。 これで仮に変換して保存したパスワードが漏れたとしても、不可逆変換なので元のパスワードへの変換はほぼ不可能で安全だ。

正確に言えば、md5やsha1では危険と言われ、逆変換されてしまう危険性があるため、より安全なsha512などを使うのが好ましい。 今現在、安全と言われているアルゴリズムであっても、将来危険になる可能性があるので注意が必要である。 今回は、有名な方法であり、PHP標準の関数で実装されている、md5とsha1を例に説明した。

ただし、この場合、管理者や開発者であっても元のパスワードはわからないので、パスワードを忘れてしまったユーザに対して、パスワードを再設定させる仕組み(パスワードリマインダ)などを用意する必要がある。

例えば、

  • パスワードを忘れたとき用の秘密の質問を設定させておく
  • あらかじめユーザにメールアドレスを登録させておき、パスワードを忘れた場合には、そのメールアドレスに新しいランダムなパスワードを送る
  • あらかじめユーザにメールアドレスを登録させておき、パスワードを忘れた場合には、そのメールアドレスにパスワード再設定ページのアドレスを送り、再設定させる
というような方法などがある。


53件中 31-35件目     [ ... 2 3 4 5 6 7 8 9 10 11 ]