132件中 101-105件目     [ ... 16 17 18 19 20 21 22 23 24 25 ... ]

調べてみるとどうも今年の8月には既に公開されていたようだが、GIGAZINEの記事で始めて知った。 少し中を見てみると、内容はGIGAZINEに「上級ユーザー用の書籍」とあるが初心者~中級者向けという感じがする。 ページには広告が非常に多く、ぶっちゃけ見にくい。 だからこそ販売中の本の中身を公開しても問題ないと判断したのだろう。


IE6では、selectタグはWindowsのコントロールを使用して表示されている。 そのためか、z-indexやborder、text-alignなどいつくかのスタイルが無視される。 特に困るのがz-indexで、JavaScriptでdivタグをドラッグで移動できるようにした場合、ページ内にselectタグがあると、selectタグだけがz-indexを無視して一番上に表示されてしまう。

selectタグがz-indexを無視するサンプル

Opera9、Firefox2では正しく表示される。 IE7ではz-indexの扱いは正しくなっているが、borderやtext-alignは利かない。

このz-indexのバグはiframeタグを使って解決することができる。


2007/11/07 22:24:15 投稿 (2007/11/20 00:52:53 更新) http://www.programming-magic.com/20071107222415/
タグ [ CSS , HTML , Tips ]
修正:
  • 画像を追加 (2007/11/20 00:52:53)

普段、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を例に説明した。

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

例えば、

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


PostgreSQLでは以下のようなクエリーでカラムを削除する。

ALTER TABLE <テーブル名> DROP <カラム名> [RESTRICT | CASCADE];
ALTER TABLE test DROP user_name;
ALTER TABLE test DROP number CASCADE;
ALTER TABLE sample DROP status_id;

最後にCASCADEを付けることでそのカラムに依存するオブジェクトがあっても削除することができず、RESTRICTを付けるか省略した場合、依存するオブジェクトが存在すると削除することができない。

以下のようなクエリーで同時に複数のカラムを削除することもできる。

ALTER TABLE <テーブル名> DROP <カラム名>, DROP <カラム名>, ....;
ALTER TABLE test DROP login_name, DROP comment;
ALTER TABLE test DROP login_time, DROP login_id;

132件中 101-105件目     [ ... 16 17 18 19 20 21 22 23 24 25 ... ]