勢い余って、IE8にアップグレードしてしまった。

でもって、ぼちぼちサイトの開発してたら問題が…

<input type="file"> のvalueが「C:\fakepath\ファイル名」になる。

これって、きちんとアップロードできるの？

そう思って、ググってみると、どうも無理っぽい（サイト構築し始めなので、ディレクトリ作ったりするのが面倒なので、本当に無理かは試してない）。
しかもIE8になってセキュリティ面の強化の賜物だとか。

でもって回避方法をメモっておく。


（１）セキュリティレベルの変更
「インターネットオプション」を開き、「セキュリティ」タブを選択。
ゾーンの中から「インターネット」を選択し、「レベルのカスタマイズ」を押下する。
で、ずーっと下の方の「その他」の中になある「サーバにファイルをアップロードするときにローカルのディレクトリパスを含める」を無効から有効に変更する。

（２）信頼済みサイト
同じく、「セキュリティ」タブのゾーンから「信頼済みサイト」を選択し、ゾーンの右下あたりにある「サイト」ボタンを押下する。
で、アップしたいサイトを信頼済みとして登録する。
「https」ではなく「http」の場合には、きちんとチェックボックスをオフにする、と。

まぁ、どうなんでしょう？

----------------------------------------------

ちょっと追記。
PHPとかはフツーにパスが取れるので、誤解なきよう。

ちょっとお手伝いをしたので、忘れないようにメモしておこうと思う。

.htaccessで一時的にアクセス制限をかけたいらしいのだけど、どうも上手くいかないってんで、ちょっと手伝ってみる。

Digest認証のダイアログをキャンセルすると、エラーに飛ばしたいんだけど、どうも上手く動かない。

最初にアレ？と思ったのは、エラーログ（error_log）を確認して「 ErrorDocument not allowed here」というエラーを見つけたとき。
結局犯人はhttpd.conf（を設定した人）だったという話。

ドキュメントルートのディレクトリ設定は
<Directory />
AllowOverride All
</Directory>
となっていたため、OKかと思われたが、実際に適用したいディレクトリにも個別に設定がしてあった。

<Directory "該当するディレクトリ">
AllowOverride AuthConfig
</Directory>

ようするに、認証に関する設定しかダメよってことですか。
これを
<Directory "該当するディレクトリ">
AllowOverride All
</Directory>
に直すことで、正常に動作しました。

あぁ…
ちょっと違うな。
上位ディレクトリ（この場合ドキュメントルート）の設定に上書きできるのが、認証だけよってことか。
AllowOverrideをAuthConfigのままにして、httpd.conf内部にErrorDocumentを追記するのでも、いいのかな？（試してないけど）

困った困った。

まぁ、基本的に無知なのがいけないんだけどさ。

誰もいなかったから僕がやったっていう発端もどうかって話だけどさ。
それなりにPGできるから、かえっていけなかったね。
たいして知りもしないで、作るものではないってことで。
知ってる人がほとんどいないって時点で、救いの手はどこに求めたらいいのか判らないという…


ユーザの入力に対して、チェックを入れたりするんだけど、これがどーもよく判らなくて。
最初に参考にした本が、SQLにINSERTするための処理として、htmlspecialchars()とmysql_real_escape_string()をかましてたもんだから、そういうもんかと思って…

結局htmlsp(ry は表示の前にやるのがいいというのは、納得できた。
たしかにDBには生のデータ（実際にはエスケープされてるけど）を入れるべきだろうな。

入力
↓
確認表示（表示用にhtmlspecialchars()を入れるけど、実際のデータはそのまま）
↓
登録（INSERTする段階でエスケープ）

リクエスト
↓
表示（DBから引っ張ってきたエスケープ済みの内容をhtmlspcialchars()で表示）

こういうこと？

PHP+PostgreSQLについてのメモ。

本当は、pg_prepareとか使えるといいんだけど、今の環境がPHPのバージョンが5じゃないので
、仕方なく…

pg_query($db, "PREPARE sample (text) AS SELECT hoge FROM hoge_tbl WHERE col_hoge=$1");
$result = pg_query($db, "EXECUTE sample ('{$number}')");
pg_query($db, "DEALLOCATE sample");

まぁ、「PREPARE」でクエリを作成するんだけど、ここで指定する変数の型(ASの前に括弧書きしてるヤツね)が曲者で（自分の確認が不十分なのを責任転嫁）、「EXECUTE」の時に入れる変数の値がintってことに全然気が付かなくて、エライ大変な思いをしたものです。

忘れないように、メモ。

シェルスクリプトとSQLの合体。

フツーにSQLを実行するの場合は…

mysql -u ユーザ名 --password='パスワード' データベース名<< EOF
SQL文
exit
EOF

ってことで。

で、実行結果を取得したい場合は

RESULT=`mysql -u ユーザ名 --password='パスワード' データベース名<< EOF
SQL文
exit
EOF`

と、コマンドの実行時と同じく「`」で括っておしまい。

SELECTの場合なんかでカラム名まで取得されちゃうので、

RESULT=`mysql -N -u ユーザ名 --password='パスワード' データベース名<< EOF
SQL文
exit
EOF`

と「mysql」に「-N」オプションを付ける。

Webサイト構築のお仕事中…

テスト環境での作業が終わったので、本番環境へ移行作業をせっせと実施。

サーバ管理者がダイジェスト認証を設定。

ログイン。

OK。

とりあえず管理画面へアクセス。
でもって、次のページへ…

行けません。

「400」だってさ。
「不正な要求」だってさ。

試してみると「abc.php?param=value」のようなURLがNGで、「abc.php」だと上手く行く。

テスト環境だと問題なかったのに…

GETパラメタの問題かなぁ？
PHPの設定かなぁ？
Apacheの設定かなぁ？

ん？
サーバ管理者のPCだと問題がない？
違いは？
僕のPCがIE6で、彼のがIE7？
なんでだろう？
他のPCでも試してみたけど、IE6だけがNGのようだ。
IE6固有の問題？
でもテストサーバじゃOKだったもんなぁ…

かれこれ2～3時間くらいでしょうか？

ついに突き止めました。

HTTP クライアントを作ってみよう(6) - Digest 認証編 -
http://x68000.q-e-d.net/~68user/net/http-auth-2.html

上記サイトにこう書いてある。

ただし、IE6 では Digest 認証を使って foo.cgi?FOO=BAR のような URL にリクエストすると、誤ったリクエストを送ってしまうバグがあります。以下の URL は Mozilla や FireFox では正しく閲覧できますが、IE6 だと正しいユーザ名・パスワードを送信しても、 400 Bad Request になってしまいます (Windows XP SP2 + IE6 で確認)。

えぇっ！？
どういうこと？？

パケットを見てみると、IE が送信した Authorization ヘッダの uri には「?FOO=BAR」の引数部分が含まれていないようです。

はぁ…
たしかにApacheのログを見ると、「?」以降があるのとないのとを比較して、アンマッチとかってなってる。

これは IE のバグですが、いつまでたっても修正されないので、 Apache-2.0.51 からサーバ側で無理矢理対応する仕組みが設けられました。 httpd.conf や .htaccess に以下のように記述しておけば、 IE でも上記のような URL に正しくアクセスできます。

書いてあるとおりに、修正を行う。
他のVirtual Hostに影響を与えないよう、.htaccessに以下を挿入。

# User-Agent ヘッダに MSIE という文字列が含まれていたら、
# 環境変数 AuthDigestEnableQueryStringHack に「On」をセットする。
BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On

正常に動きました。
php.iniのdiffを取りました。
httpd.confもdiff取りました。
相違点はここくらかと思ったけど、まさかダイジェスト認証が問題になるとは…
よく考えれば、テスト環境ではダイジェスト認証をかけてなかったわ。

辛いなぁ…

PHPの話題。

最近、PHPをアレコレする仕事が多いのですが…

デザインも上がってきて、僕の作ったロジックと合体！と思って作業を始める。

サーバ管理者が、デザインチームのHTMLをアップしてくれたので、ブラウザから確認。
UTF-8で作ってあるのね。
OK、OK。

でもって、デザインと合体しない管理画面をまずはアップして、アクセスしてみる…

…え？

文字化けしてんじゃん。
正確には、文字コードを正しく認識してない。
ファイルはUTF-8で保存してるし、METAタグでCHARSETをUTF-8にしてるのに。

まずは自分を疑った。
でも結局は、php.iniの問題だと発覚。

default-charsetがSHIFT-JISになってました。
なので、HTMLは正しくUTF-8と認識されて、PHPのファイルだけがSHIFT-JISと認識されるという状態になってました。

あとはmbstring関係とかも確認しておかないとね。