久々に仕事ネタ。CentOS6系+PHP5.6&ZendFramework2。

 Zendframework2ベースの開発で、でもZend::Mailだと日本語のあれこれに難があるっぽいので旧来通りのmb_send_mailを用いた添付可能メール配信クラスを作成。
 とりあえず正常に配信されるようになって一安心、でも色々試してみるかと確認してたところ
 「Thunderbirdで保存したemlファイルをOutlookで開くと、添付ファイルの中身がNullで埋まってる」
 とゆー現象に遭遇。試しに直接Outlookで取得するアカウントを作って送付してみたところ、そのシステムから送付した全ての添付ファイルが同じようになっている。ファイル名は正しい。ファイルサイズも正しい。でも中身が空っぽ。いやNullで埋まってるので空っぽではないのだが。
 Thunderbirdでは問題なし。Beckyでも問題なし。Gmailでも問題なし。Web版Outlookでも問題なし。・・・にも関わらずアプリ版Outlookではそうなる。

 色々調査&実験。emlファイルをテキストエディタで開き、添付ファイルのContent-Typeを別のものに書き換えたらうまく読めるようになった、という事があったのでメール送信側を変えてみたがダメなまま。じゃあなんで書き換えたらうまく行ったんだ?と疑問に思い、試しに「開く→何もせず保存」したところ読めるようになった(苦笑)。ここで何かしらの自動変換が影響してるものと推察。まあきっと改行コードだろう。

 元ファイル、及び元ファイルを開いて保存しただけのファイルをテキストエディタで比較してみると「違いはない」と言われる。改行コードも変わってないように見える。
 次に同じ比較をバイナリエディタでやってみる。すると「添付ファイルをbase64化した部分」の各改行コードが「\r\r\n」となっていることが判明。なるほどコレか。メールのCRLF問題っちゃ久しぶりだ。

 改めて添付ファイル部のコードを見る。やり方はネットでよく見かける手法で、ファイル添付部は以下のようにしていた。

  (この前で別のbody部を設定しつつ)
  $body .= chunk_split(base64_encode($attach))."\n";

 ここで改めて「chunk_split」について関数定義を見てみると

  string chunk_split ( string $body [, int $chunklen = 76 [, string $end = "\r\n" ]] )

 であり、非必須の第3パラメータが分割された各行の改行コードとなる。なるほど、他のところは全て「\n」、すなわちLFだけで指定してるのに対し、添付部はここで\rが余計に入っちゃったのか。

 第2パラメータは標準の76として、第3パラメータを「\n」のみ指定に変更。結果、無事Outlookでも添付ファイルが取れるようになりました、とさ。


 しかし世の中見てるとchunk_splitをそのまま使う記述例ばっかで、かつOutlookで添付ファイルに問題が発生したなんて話はほとんど見かけない。他の人はこーいったトラブルに遭遇してないのかなぁ。
 この手法そのものが今となってはあまり使われてないということなのか、それとも実行環境がWindowsベースで改行コードの問題が発生しにくいということなのか。あ、今回MTAはPostfix使ってるんでその辺が影響してるのかもしれない。今時MTAを自分のシステム上に持つなって話なのか?

 つか大抵のメールクライアントで対応できる事柄をいつまでも放置してんじゃないよ>MS、といういつものテンプレがオチなんだろう。
 





 

2015-12-25 [技術・作業]

 いつかどこかで変な問題起こして損する人が出てくるだろーと漠然と遠巻きに見ていたBitcoin。

 …それはそーとコードはPHPなのか…。軽く見た感じ、典型的な「これまでWebアプリ&オブジェクト指向でやってこなかったプログラマがとりあえず渡されたクラスだけ説明通りに使って作成したプログラム」のよーに見えます。仮想とは言え通貨を扱うプログラムでこんな問題起こすからPHP使いはPHPerとか言われて問題視されるんだよ…。

関連タグ:PHPBitcoin
2014-03-04 [事件]

 記事タイだけ読むと「コード埋め込まれたJPEG見るだけで感染するマルウェアが出た」よーに思えてしまうが、あくまでそれと連携する「悪意を持ったPHPサーバ」がいることが前提であり、発動のキーはそのJPEGを見ることではなくそのPHPページを開くことなわけですな。コードと一緒にその画像があればそのページ見ただけで発動はするのでしょうが、この手のは分散させますかね。
 また「PHPのコードで」云々書いてあるせいでややもすると「PHPで書かれたサーバが乗っ取られる?」的な不安にかられるところですが、「サーバ上にPHPで書かれた悪意あるコードが存在する」のが前提であって、元々何らかの手段でサーバに対するアクセス権を持ってない限り仕掛ける事は出来ないので、コレをもって即PHPサーバが攻撃を受けるとかゆー話でもないですな。もちろんXSSとかで遠回りした結果乗っ取られる可能性もあるのでしょうが。

 今回の件は「悪意あるWebサーバが閲覧者に知られずにバックドアコードを仕掛けるために、JPEGのEXIFにコードを隠す手法が見つかった」と言うのが正しいでしょうか。…まだ分かりづらいかw
関連タグ:PHPマルウェアJPEG
2013-07-17 [セキュリティ]

 と、言う話らしいですが、十数年来のPHPerである私としましては控えめに申しましても

  「二度とIIS+PHP構成なぞ組むかURIIIIIIIII!!」

 と言うのが本音でございます。
 WindowsでPHP動作させたい場合はZendServerCEが一番手っ取り早いとゆーのが結論です。ZendFrameworkを動作させる場合は尚更。
2013-06-24 [技術]

 色んな理由からLinuxからWindows(Server)の操作をしたい事があります。
 専用のAPIやらRPCやらを持ってるモノだったらそこに対してアクセスしますが、内部コマンドについて処理をしたい場合何らかのCLI系サーバをWin側で立ち上げるか、はたまたIISとASP等を経由して内部コマンドを実行、といった手段があります。

 そんな手法の1つ、「LinuxからWindowsのコマンドを直接実行する手段」としてsamba系のツール「winexe」があります。と言うかあることを最近知りました。これはWindowsで言うところの「psexec」に似ており、コマンドプロンプトで実行するようなコマンドを実行することができます。

 で、更にPHPのexec関数やらsystem関数やらを使う事でLinuxベースのWebアプリからWindowsの特定制御を行う事を試みたのが今回のお話です。そんなことしたい人間がどれだけいるかって話です(苦笑)。
 とりあえずLinuxはおなじみCentOS5系でPHPは5.1.6。WindowsはServer 2008 R2。winexeは1.00。

 winexeのインストールは割愛。ソースコンパイルして適当なbinにコピー。
 適当にコマンドテスト。

   winexe -U "Administrator%pass" --system //[HOST] ipconfig 1> /var/log/test_winexe.log

 とりあえず出力をファイルに書いてます。結果ipconfigの結果が素直に返って来て感動。但し今更SJIS。まあコマンドプロンプトだから仕方ないか。

 で、次にこれをPHPのexec関数から実行。

  exec("winexe -U \"Administrator%pass\" --system //[HOST] ipconfig 1> /var/log/test_winexe.log");

 …ところがコレが何時まで経っても応答が返ってこない。psでプロセス見るとコマンドは発行されて止まってる様子。killしないと残りっぱなし。
 ログファイルを見ると

   tevent: EPOLL_CTL_ADD failed (Operation not permitted) - falling back to select()

 というエラーが1行。
 「permitted」云々言ってるんでアクセス権かな、と思いsudoによるroot権限実行に変更。しかし変化無し。
 他の実行コマンド系はどうだろう、と「system()」「shell_exec()」を用いるものの変化無し。
 またコマンド内容をシェルスクリプトに移動し、そちらで起動しても変化無し。

 sudoでもそうだったがこういった場合標準出力関係でトラブる事が多いので、似た状況で稼働するcronでの起動を試す。ユーザはPHPの稼働環境と合わせる意味でapache。しかしコチラは無事に稼働。TTY及びapacheユーザ権限の問題の可能性が薄れる。

 仕方ないので(いや最初からやれよと)元々出ているエラーメッセージを追うことに。
 「EPOLL_CTL_ADD failed」はコネクション系のエラーぽい。しかしここで「Windows側に処理結果が残るバッチ」を作成して実行したところ、そちらの稼働は確認できた。つまるところ「コマンドを読んだ後の戻り」が上手く言ってない様子。

 そうなると、どちらかというと「PHPから起動した故にプロセスの戻りのパイプがよくわからんことになっている」という可能性があるのかなと。EPOLLについて調べてたらファイルディスクリプタがどうこう言われたし。
 なので上記シェルの起動を、プロセス単位で制御する「popen()」に変更。そしてポインタを開く際の権限モードを書き込み可能な「w」で動くように設定。

  $pp = popen("winexe -U \"Administrator%pass\" --system //[HOST] ipconfig 1> /var/log/test_winexe.log","w");
  pclose($pp);

 上記の様にしたところ、無事終了しつつ且つ結果も取れるようになりました。
 更に実験で上記popenの権限モードを読み専用の「r」に変更したところ、他のexecやらと同様に停止しつつプロセスに居残り、また同様のEPOLL_CTL_ADD系エラーが発生することを確認しました。


 まーこんな話が世の中役に立つかはアレですが、他の実行ファイルを起動する場合にも似たような話が発生する可能性はあるでしょう。まあ一例ってことで。
2012-09-01 [技術・作業]

 ちと実験中。PHPのLDAP関数を使ってActiveDirectoryのグループやユーザ情報を操作したい場合の話。まず可能不可能で言えば「可能です」。
 なおPHPのバージョンは少し古くてCentOS5系列準拠の5.1.6。WinはWinSvr2008R2。

  • まずはTLS接続できること。「変更」をしたい場合は必須っぽい。自作証明書で可。
  • Linuxのphp-ldap経由でADにTLS接続しようとする場合、OpenLDAPクライアントの設定に左右される。で、ADサーバを自作証明書で運用する場合、自作証明書をOpenLDAPに設定するか、あるいは「/etc/openldap/ldap.conf」に「TLS_REQCERT never」の1行を追加して証明書の正当性判断を完全に殺す。後者がてっとり早くはあるがなりすまし判断は全くできなくなるので注意。
  • ldap_connectでの接続先は「ldaps://」ではじめる。
  • 「Administrator」権限でbindできれば一通りはできそうな感じ。
  • ユーザアカウントを特定グループに所属させる場合
    • ユーザ側から見た所属グループのattributeは「memberof」だが、これは操作できないっぽい。
    • なので逆にグループ側のattribute「member」にユーザを追加する。こうするとユーザのmemberofも自動で追加される。
  • ユーザアカウントのパスワードattributeは「unicodePwd」。これはいかなる方法を持っても閲覧は不可、らしい。
  • 別に読めなくても追加や変更はできる。
  • 一般的に、unicodePwdに入る値は「パスワード平文をダブルクォーテーションて括ったもの」を「UTF-16LEに変換」し更に「base64でエンコードする」とある。
  • 上記を真正直に捉えて下記のようにやろうとするとハマる。
    •  $arrEntry['unicodePwd'] = base64_encode(mb_convert_encoding("\"newpass\"","UTF-16LE"));
    •   ldap_mod_replace($ld,$txtDn,$arrEntry);
  • どうもPHPのLDAP関数はbase64エンコードを自動でやってくれるようで、1行目のbase64_encodeは不要っぽい。LDAP関数って前からそうだっけか?
    •  $arrEntry['unicodePwd'] = mb_convert_encoding("\"newpass\"","UTF-16LE");
    
関連タグ:PHPActiveDirectoryLDAP
2012-08-23 [技術・作業]

 今日のアクセス履歴で「zendserver documentroot 変わらない」とゆーワードで来た方がいらっしゃったのですが、ひょっとして以前私が引っかかったのと同じ理由かもしれないので備忘録として記載しておきます。 

 その前に軽くご説明しときますと「ZendServer」とはPHP及びZendFrameworkを稼働させるためのWebアプリケーションサーバ。その実体はApache+PHPにZendFramework環境を搭載し、且つサーバ操作・設定用のGUIを搭載したもので、それぞれを個別にインストールするよりかは簡単にZendFramework環境を構築できるものです。LinuxだったらApache+PHPは標準として入っている事が多いのでZendFrameworkを入れてApacheを設定するだけなのでそれほど意味はない(※最適化とか別の利点はありますが)ですが、Windowsの場合にApacheごと1つのインストーラで導入できるので、それぞれを個別にインストールしたり、あるいはIISでPHPを動かす設定を行うより楽に環境が構築できます。プラットフォームを変更する可能性がある場合にも有効でしょうな。
 そいや何年か前に「IISでもPHPがちゃんと動くようになったよ!」とMSが盛んに言ってる時期があったけどアレってどうなったんでしょね。個人的には結局「PHPを動かすのにIISを選択するもんじゃない」とゆー結論に達しましたが。
 話を戻すと、結局のところインストールされるものはフツーにApacheでありPHPなので、設定方法は通常通りhttpd.confやらphp.iniやらのテキストを編集することで可能です。一部設定はGUIでも可能ですが慣れてる人は直接confなりiniなりを編集した方が早いと思います。DocumentRootの設定も然り。

 …と、前置きが長くなりましたな。ぶちゃけそんな複雑な話では実はなく、それどころかZendServerの話でもなく。
 インストール対象のOSがWindows7や2008Serverなどで、ZnedServerのインストール先を「Program Files」(含む(x86))にしてしまった場合、あのフォルダの配下はいわゆるUACにより通常権限でのファイルの書き換えができなくなっているため、「フツーの方法でテキストエディタなどからhttpd.confを開いて保存しても正式な登録として反映されない」とゆー罠があります。コレがヤらしいのは正式に登録はされなくてもどっかに仮保存されてるらしく、保存→再び開くとちゃんとデータが書き換わって見える点。なので「あれー?ちゃんと設定ファイル書き換わってるなー、でも設定反映しないなー」とすげー悩む事になるわけです。コレは「Program Files」配下に限らずWindows配下のhostsファイルとかも同様。
 とりあえず対処方法はメモ帳などのテキストエディタを右クリック→「管理者として実行」で管理者権限起動し、その上で「ファイル」メニューから目的のファイルを呼び出して編集→保存すること。対象ファイルをD&Dしてはダメ。
 根本的な対策としては「Program Files」とかのUACによって特殊な管理をされているフォルダを避けてインストールすること。 ま、セキュリティ的にそれが良いかどうかは別物ですが。

 そもそも根本的な問題としてUACの制御方法が一般人にとてもわかりにくい、とゆーこれまで議論百出した話になるわけですが。まあその可能性さえ押さえておけば他のアプリや設定ファイルで同じ事象が発生してもピンとくるかと思います。
2012-03-12 [技術]

 久々にPHP話だよ!

 CentOS5系列最後の方をベースに、毎度おなじみZnedFramework+Smarty+PostgreSQL環境で開発しております。
 このディストリになるとインストされるPHPを5.1.6系列か53系列かを選択できる。まあ一部足りないモノがあったりもするのだが、この間には越えられない壁があると判断。
 またPostgreSQLも8.1系列と8.4系列を選択できる。ここにも超えられない壁…というか今回xml型を使いたかったので8.4を選択。まあこの2者のため「PHP53からPostgreSQL84につなぐ」ための設定に少し手間取ったりもしたがそう大した話ではない。

 さてちまちま開発する中でそりゃ使うだろうという関数が日付関数「date」。今まで一度も使わなかった事はないね、とゆーくらい頻繁に使うこの関数だが、今回デフォのphp.ini設定のまま使うと
Warning: date() [function.date]: It is not safe to rely on the system's timezone settings.(中略)
とか表示される。まあWarning非表示にして無視するという選択肢もあるが、標準的な手法としては設定ファイルphp.iniの「date.timezone」に適切な値を設定すれば良い、ということらしい。らしいので日本標準時を指定する「Asia/Tokyo」を設定し再起動…うむ、エラーは出なくなった。


 …と、一般の手法で上手くいかないのが私のパターンw

 確かにエラーは出なくなった。が、なんか表示される時間がおかしい。
 気づいたのはPostgreSQLに設定された時間がずれていた事。当初はてっきりPostgreSQL側のtimezone設定がおかしいものと思って調整したが変わらず。と言うか「select date();」で普通にJST返ってくるし。
 上述のphp.iniの書き方がおかしいのかなー、と思い色々試すが変化なし。が、ここで先日遭遇したCentOS自身のtimezoneを指定する「localtime」がおかしいよ話を思い出す。ひょっとしてPHPもここの解釈おかしくなってんじゃないか?と言うかどっかでまとめて時間管理してるのか?と思い、試しにphp.iniに時差の少ないであろー「Asia/Seoul」を設定したところ本来のJSTに近い時間が表示された。やっぱりかAAAAAAAAA!!!!
 ちなみに見たところ「Asia/Tokyo」設定で返されるのはGMT-5時間くらい。位置的にはペルーとかの南米付近で間違いようがない…のだが敢えて間違う可能性があるとすると同じ「Ja」から始まる「Jamaica」と取り違えた…のだろうか…。

 しかしこんな話が一般的だったらもっと世の中騒いでてもいいはずだが、軽く調べた限りこんな事で困ってる人はいないようだなぁ。なんかウチの環境だけ特殊なんだろうか。日本限定で。
 そしてこれの対策は…どうしたもんかなぁ…w


追記:
 対処方法編。基本的には前のCentOS・/etc/localtimeと同様。このファイルの本来のコピーorシンボリックリンク元であるところの「/usr/share/zoneinfo/Asia/Tokyo」をどうやらPHPは参照しているらしい。なのでコレを前回同様1つ前のソレと置き換えればOK。
 …しかしなんでこれだけこんな状況なんだか。「yum update」でまとめて更新するとこの間違ったファイルに置き換わってしまうようだが。他国の嫌がらせかw
2012-01-19 [技術]

 ふむ?中々に面白い試み。ここ最近PHPってあまり目立った動きがないかなーと思ってたけど色々やってるところはやってるのねぇ。
2011-12-21 [ソフトウェア]

crypt()をMD5のsaltで実行した場合、saltしか返さないというもの。

 なかなかに豪快というか吹く内容のバグだ。むしろ意図的な混入すら疑えるよーにも思うが…さて。
関連タグ:PHP脆弱性バグ
2011-08-24 [技術・作業]

 何故か昨日辺りからPhpMyAdminの脆弱性などを狙ったアクセスが増加してきた。具体的には

 /PHPMYADMIN/scripts/setup.php

 等の管理ページへのアクセスを狙ってくるもの。アクセス元は国外でバラバラ。まあアテにはならないが。
 本サイトはMySQLを使用してないので当然PhpMyAdminも存在しないのだが、ZendFrameworkのルーティング機能を用いているため、とりあえずどんなアクセスでも受け付けつつErrorControllerに流され、結果404エラーが返らないようになっている。何かしら応答がある!と思ったbotがチョーシに乗ってるのかもしれない。もっとも404を返したとしても試行されるのは変わらないだろうが。

 まあパターンは分かってるのでそのうちFBIにでもリダイレクトするように仕向ける予定。
2011-02-10 [セキュリティ]

 2011年初頭から1ヶ月経過して2月。本サイトver.5のβ版運用が始まってからはほぼ2ヶ月。その間ちまちまと完成に近づいてはいるが、逆に言えば未だ完成は見えず。そのココロはと問われると、ひとえにめどいからと答えよう(苦笑)。さすがに全コーディングをイチから見直すとなると大変でのぅ。今回コードの再利用率は10%未満だろーからなぁ。まあZendFrameworkのおかげで相当高速で書けてはいるし、主要な機能はできあがってるのでまあ良いのだが。

 そんな中、先日じみーに機能復活したのが「カウンタ機能」。最近はあんま流行らなくなった機能だけども、せっかく今までじみーにカウントしてたのがもったいない気もしたので。それに、どーせアクセス制御系の機能とアクセスログ系の機能は作らなきゃいけないから、それに組み込めばいい話だし。そんなわけで、復活したカウンタ機能の裏ではアクセス制御機能とアクセスログ機能が同時に復活したわけです。

 アクセス制御はその名のとーりアクセス可否を判断する機能。特定条件によるアクセスの拒否から、一定時間内過度アクセスの排除などを担うと共に、カウントアップ実行の判断などを行っております。カウントアップするかしないかはクローラ等除外の他、同一IP一定時間内カウントアップ禁止などを行ってます。以前はその判断のためにDBにアクセス時間を書き込んだ上で都度検証を行ってたワケですが、それは当然相応のトランザクションの発生を意味しており、それなりに速度低下を招いていただろなぁ、と。
 それに対し今回は、先日ちと話題に出したmemcached+Zend_Cacheを利用したメモリキャッシュ方式に変更。生存時間を設定できるキャッシュのおかげで大した苦労もなく判定できるようになった。アクセス制御等も同様。ちなみにカウンタ値も実は普段はメモリキャッシュに書き込みつつ、一定確率でDBにアップデートかけるGCもどき風味に。若干カウンタ値の欠損の可能性があるものの、これも負荷軽減にはけっこー効果があるんじゃないかと。

 アクセスログは…まあアクセスログ(苦笑)。別にApacheのログ+Webalizerでええやんとゆー話はあるものの、検索エンジンのキーワード解析とか、それらのデータマイニングを考えると、自前で取って且つDBに入ってた方が都合がよいので。
 こちらも以前は全てDB…PostgreSQLに都度書き込んでいたワケだが、やっぱそれはそれでトランザクションがアレ的な事になるだろう、と。前Verではログ書き込み部分をWebアプリ部から分離してシェル化し、表面的な体感速度の向上は図ってたので、更に今回はログの書き込み先をsqliteに変更してトランザクションそのものを分離。DBファイルは1日単位で作成する形式とし、1日単位でのデータ解析をやりやすいように。まあ逆にトータルでのデータ解析はやりづらくなってるかもしれないが(苦笑)、まあデータの統合はいつでもできるので。
 また、メインDBであるところのPostgreSQLは高速性を考慮して実体をSSDに置いてるが、ログDBはそんな必要もないので外付けのHDDへ書き込み。…これはむしろSSDの寿命を考慮しての事だったりする(苦笑)。

 …とまあこんなカンジで、表面上はほとんど現れない部分に結構苦労してたりします。めんどくさいのは分かってたのでイマイチ手を出す気になれなかった部分。でもまあ苦労の甲斐あって、以前と比べて色々高速化・最適化されたカンジがします。苦労したと言いつつ前verよりも環境整ってるんで比較で言えば楽だったんだけどね。
 あとメモリキャッシュ周りに手を出したついでに、頻繁にアクセスされるであろうトップページ(ルート)のデータ、及びRSSのデータをメモリキャッシュに置くことでの高速化も搭載してみた。ここんトコはアクセス解析と併用すれば更なる効率化が望める事だろう。

 つーことでちょびっと完成に近づいた。完成目標は今年度内!…ではあるものの飽きたらその限りにあらず(苦笑)。
2011-02-01 [日記]

 Webアプリ高速化の手法として良く見かけるようになったmemcached。標準状態のCentOSだとrpm、yumとかで入らないのでこれまで放置してきたが、今回システム入れ替えに伴い、自前で共有メモリを使って処理してた部分をmemcached+Zend_Cacheで置き換えようと考えた。

 それほどメモリが潤沢にあるサーバでもないんで(なんせCF-R3なので)キャッシュにおける情報はそれほど多くはない中で、キャッシュに入れる情報を吟味する必要がある。もちろんブログのように本来DBから読みだされてテンプレートを経由して表示、されるようなデータをキャッシュしとくのが効率的なのでそれも追々検討予定なのだが、取り急ぎ効果を確認したかったのがZend_Config_Iniで取り込まれるいわゆるINI形式ファイル。
 INI形式で取り込まれる定数系のデータは、基本的にそう頻繁には変更されず、一方でシステム全体に絡む設定が多いのでアクセスの度に読み込まれるものが多い。これをメモリキャッシュに置くことでどれくらい高速化されるのかを検証してみた。

 試験用として60個くらいの定数を持つINIファイルを作成。キーで6~7個くらいに分化されている。これをZend_Config_Iniで取り込みtoArrayで配列化したものをキャッシュに置いた状態をスタートとし、キャッシュの読み込み10000回にかかった時間と、ふつうにZend_Config_Iniで10000回取り込みにかかった時間を比較してみた。
 なおINIファイルの置き場所はSSDなので、HDDに置かれるよりかは高速に読みだされているものと思われる。

 結果。
   キャッシュ読み:1.63秒
   INI読み:9.17秒

 まあ当たり前だけど結構な差が付いた。頻繁に読まれるファイルだけに効果は大きそう。INIに入ってるデータってそんなに多くもないから(少なくともウチのシステムでは)メモリ的にもそんなに圧迫しないだろうし。とりあえずその方向で調整してみよう。

 あとはトップページや、アクセスランキングで上位に来る情報を優先的にキャッシュするよーにすれば結構高速化できそうな感じ。
関連タグ:PHPZendFramework
2011-01-24 [技術・作業]

 むう、PHPがランクを落としている。ZendFrameworkとか導入してコーディングの流れをがらっと変えるとまたイメージ変わると思うんだが、というか変わった。最近はZendServerで導入も楽&プラットフォーム依存も縮小してきてるし。
2011-01-12 [ソフトウェア]

 ちなみにこの関数は5.3から追加されたものなので、5.1.6をベースとしているRedhat5系クローンの提供PHPを利用している場合は問題なさそうです。
関連タグ:PHP脆弱性
2010-12-03 [セキュリティ]

ほほう。備忘。対応版のZend Serverも近いうちに出てくれるとありがたいのだが。
関連タグ:PHPZendFramework
2010-11-08 [ソフトウェア]

 今更ながらAJAXネタ。最近ようやく手を出せる状況になったもので。

 AJAX導入の利点として、従来のWebアプリでは不可能だったダイナミックな動きを実現できるというものがありますが、それはつまるところ「ユーザインターフェースの改善」という一言に尽きるかと思います。
 実際Webアプリはその独特の制限…「何かのアクションは別ページを開くことで実行される」というのがあるため、使ってては違和感、作っててはもどかしさ・及びそれを何とかしようとした際の煩わしさが常につきまとってました。
 今回それらを打開するための実験と称していくつかAJAXの実験をしてみようかと思います。

 その前に、まずAJAXを実現する環境としてxajaxを導入してみました。詳細は他ページに譲りますが AJAXをより気楽に使おうというPHPのクラスライブラリで、簡単なものであればほとんど独自にJavascriptを書くことなく AJAXが実現できるとゆー便利なモノです。Javascript苦手なんでありがたい。

 さて、今回試して見たかったのが「登録」ボタンの類を無くせないだろうか、というもの。
 データ登録が絡むWebアプリの場合、大抵
入力フォーム
  ↓
入力内容チェック
  ↓
実登録
という流れで行われると思います。この遷移が全部別ページで行われる事もあるだろうし、1つのページの中でフラグ分けで実現される事もあるかと思いますが、やってることは同じです。その間ユーザは(実際のデータ登録は抜きにして)「確認」「登録」の最低2回はボタンをクリックする必要が出てきます。もちろんはしょって1回にすることもできますが。
 この「ボタンをクリックする」という行為は一見なんでもない事ですが、ユーザに与える心理的なストレスというのはバカにならないと思うのです。普段そんなこと気にしている人はいないと思いますが、「さあいざ実行してやるぞ」という暗黙の気構えがあって始めて「確認」ボタンやら「登録」ボタンやらは押せると思うのです。逆の言い方をすれば、この気構えが無い人は、どんなに便利なシステムでも利用しない事すらあると思うのです。

 極力ユーザ側に「決定の意思表示」を減らしたUIを作れないだろうか。もちろん全くゼロにはできないだろうけど。
 という方向性の元、とりあえず考えたのが「『登録』ボタンの類を必要とせずに書くだけで保存できるメモ帳の類」が以下のソース。済みませんが環境内容とかはテキトーに読み替えて下さい。


<?php

////////////////////////////
// xajax即時書き込みテスト
////////////////////////////

require ('../xajax_core/xajax.inc.php');

$xajax = new xajax();

// 関数登録
$xajax->registerFunction("testFunc");

// データ保存用関数
function testFunc($arg) {

// 入力されたデータをファイルへ保存
// ※チェックとかは全然してないので注意
$fp = fopen("test.txt","w+");
fwrite($fp,$arg);
fclose($fp);

$objResponse = new xajaxResponse();
return $objResponse;

}

$xajax->processRequest();
?>
<HTML>
<HEAD>
<TITLE>xajax-test</TITLE>
<?php $xajax->printJavascript('../'); ?>
</script>
</HEAD>
<BODY>

<div id="div1" name="div1"> </div>
<TEXTAREA id="ta1" name="ta1" cols="60" rows="20"
onkeydown="xajax_testFunc(document.getElementById('ta1').value);"></TEXTAREA>

</BODY>
</HTML>


 実施していることは至極シンプルです。対象となるTEXTAREAにキーイベントをとらせてキーが押される度に TEXTAREAの内容をサーバ側に送信します。受け取ったサーバ側は愚直に内容をファイルに上書きしているだけです。たったこれだけですが、書くだけでサーバ側にテキストが保存されるとゆーのは意外なほど面白かったりします(笑)。
 あ、ちなみに「メモ帳みたいなもの」と言いましたがコレには初期表示時にファイルの内容を取り込むルーチンがすっかり抜けてるので(笑)このままではメモ帳としては機能しませんのでご注意くださいw

 コレの欠点としては「キーを押す度にTEXTAREA上の全てのテキストが送信される」ことでしょう。文字が増えれば増えるほど送信されるテキスト量は増えるし、キータッチ1回毎に送信されるのでかなり頻繁に送信が行われます。理想を言えば入力されたキーの内容だけ1文字ずつ送信するのが良いですが、さてそんなんできるでしょうか。DelとかBSとかもあるだろうし。
 ただこれはまだ愚直に書いてるだけなのでセッションやら共有メモリやらを使って効率化することは可能だと思います。こーいったのを組み合わせてWebアプリっぽくないUIを作り、ユーザビリティというより利用率を上げたい、と言うのが今の研究課題だったりします。
関連タグ:PHPJavascript
2007-08-10 [技術・作業]

 PHPには「比較演算子」と言うものがあります。…いやわざわざ改めて言う事じゃないですけどさ(苦笑)。
よーするに「==」「>」「<」の事です。

 この比較演算子を使って分岐処理、ってのは一般的によく行われてる処理なワケですが、PHPで比較演算を行う場合に、比較対象の変数が「文字列」なんだけどその中身が「整数」として解釈出来る場合、自動的に整数と判断して比較を行います。
例えば
$a = "001";
$b = 1;
if($a == $b) {~}
 と言った処理があった場合、文字列$aの「"001"」は整数「1」と解釈されて、if文がTRUEと判断されます。桁指定の文字列で数字を表してるような変数があって、それを実際の整数と比較する際に、整数変換やゼロサプレスが不要という利点があります。
 まあ現実的にはこの利点を積極的に利用する、と言うことはあんまりなく、たまたま文字列の数字型だったんだけどそのまま数字と比較することもできたから楽だったな、と言った後付けの便利さではあります。というか、普通は比較する対象の変数の型は作成者が明確に意識してるハズなんで、あんまり意味はないけど、別に悪さをするものでもないのでそのままにしてる、と言った方がいいかもしれません。僕的に、ですが。

 ところがコレがちょっと微妙な罠を作りだしまして(苦笑)。

 とあるシステムで、登録内容を管理するのに16進数桁の文字列で内部IDを管理してたシステムがありまして、つまるところ000〜FFFのよーな範囲で処理しておりました。ホントの16進ではなく文字列にしたのはその方が柔軟にコントロールできるからでした。
 で、その内部IDが一致してるかとかの判断をフツーに
if($id_1 == $id_2) {〜}
みたいにやってて、途中までは全然問題なく動いてたワケですが、ある特定の2つのIDで、どー見ても中身が一致してないのに同一のモノであると判断する現象が発生。

 まず両者の中身が別物なのは確か。参照で同じ所を見てるとゆーネタも無し。また、発生する2つのIDに限らず近い値の場合でも発生する。しかしある程度値が進むとまた別の値と判断するようになる。
 明らかに異なる文字列を、なんらかの理由で同じ値と判断してる、としか思えない。ここで頭に浮かんだのは上記の型変換。しかし症状が発生してる文字列を見てみるとアルファベットが記述してあるので数字とは判断されない、ハズ。
 同じ値と判断してるのは「0E1」と「0E2」と言った、真ん中に「E」を挟んで両端が数字になってる文字列…。

 「E」…?

 つまりアレです。数字を挟んで間に「E」がある文字列の場合、指数表現されてる整数として判断してたワケです。 0E1の場合0x101=0、0E2の場合0x102=0…つまりどっちも0として比較してたため比較がTRUEになっていた、と。中途半端に16進型をテキスト表記したのが祟ったか(苦笑)。
 ちなみに対処法は簡単で、変数比較を「==」でやってたところを「型の一致」まで確認する「===」に変えるだけ。

 まあ、よっぽどの事が無いと遭遇しない変なパターンではありますが、これにかぎらず PHPの「==」はごく希に想定外の動きをすることがあるので、使う変数の内容が明確ならば「===」を使っていた方が安全なのかもしれません。
関連タグ:PHP
2007-05-18 [技術・作業]

 これまでPHPでいくつかシステム開発を行ってきたワケですが、お恥ずかしい話ながら複数開発者がいるような環境でもこれまで特に「バージョン管理」ってのを行ってきませんでした。

 や、まあヒトの手による記述程度のバージョン管理は行ってきましたが、あくまで当事者達の主観によるものでありそれらが共有される事はあまりなく、つまりはバージョンの意味合いが曖昧になりがちでした。
 また、同じファイルを数人でいじる事もあったため、「声かけ」という初歩的な回避策しかとれない環境ではバックアップのタイミングやら戻しやらでのデグレも何度か発生し、且つソレの原因がどこにあるか判別付かないパターンが何度かありました。

 なんとかしたいなあ、と思いつつも具体的な手法となると色々環境による制約がついてしまってイマイチ導入に踏み切れない。世の中的には「バージョン管理」というと「CVS」がほぼ代名詞になってるっぽいなあ、などと色々調べてるウチに、ひっかかったのが標題の「Subversion」。CVSを踏襲しつつ弱点を補う事を目的として作られたモノっぽい。色々情報見てるとよさげだが、一貫した情報が欲しかったので書籍を購入し、翌日には稼働開始させました。インストールやら初期導入やらは他に詳しいサイトさんが多いので割愛します。

 さて、とりあえず導入したのは例によってLinuxのPHP+Smarty環境。ヒトが作ったシステムの改修なのですがどーもあまりPHPもSmartyも知らないヒトが作ったっぽく、テンプレートフォルダを堂々とDocumentRoot下に置くなんだかなぁ設計。
 まあおかげでリポジトリは作りやすかったですが。とりあえずDocumentRoot下を丸々インポート。と同時にこのシステム、管理者用に仮想フォルダが一個あるんでそちらも別にインポート。

 さて今回は開発環境はWindows端末を想定。今までならLinux上でvi使いやがれ、と言うのが基本方針なんですが(笑)、そうすると一般開発者のバージョン管理にSubversionのコマンド操作を強要する事になる。中にはPHPのコーディングも微妙なヒトがいたりするので(苦笑)余計な負担は極力減らした方がいい、と判断。 Windowsで簡単にSubversionをコントロールできる「TortoiseSVN」を導入しました。

 そのTortiseSVNとの通信を行うために、Subversion付属の簡易サーバ「svnserve」を稼働。そもそものリポジトリ構成を
一般用:  /repos/normal
管理用:  /repos/admin
とした際に、svnserveの起動オプションを
svnserve --daemon --root /repos
と指定。こうすることでTortoise側でアクセスする際に
一般用:  svn://[サーバ]/normal
管理用:  svn://[サーバ]/admin
と分けて個別にアクセスすることができるようになります。

 さて、PHPは当たり前ですがWebアプリケーション。特定のDocumentRoot下、要するに今回の場合インポート元フォルダの内容が更新されないと修正の結果がWeb上に表れません。
 なのでDocumentRootもリポジトリからデータをチェックアウト→更新の流れにする必要があるわけですが、各個別の開発者が自分に関係するファイルをコミットする度にサーバ側で「svn update」をするのはメドい。各自のコミットが成功したら、DocumentRootは自動更新されるのが望ましいわけです。
 それを実現するのがいわゆるフックファイル。各リポジトリディレクトリの「hooks」ディレクトリに置かれ、コミットの前後など特定のタイミングで稼働するシェルファイルです。
 今回の場合、コミット後に稼働する「post-commit」に「/usr/bin/svn update [DocumentRoot]」みたいに記述することで、クライアントのコミットと同時に自動更新される環境が構築できます。



 なんてな(笑)。

 いや上記の方法で自動更新一応できるはできるんだけど、状況?環境?によって出来ない場合もあるっぽい。「post-commit」そのものはちゃんと動作するのだが、「svn update〜」がちゃんと動かない環境がある。
 今回の場合、具体的には「一般」のDocumentRootは問題なく更新されるのだが、「管理」のDocumentRootの更新が行われない。
 試しに1つのpost-commitに一般、管理双方を更新するコマンドを記述し、且つその結果をリダイレクトでファイルに書き出してみたんだけど、更新される一般側はその結果がファイルに残るのだが、更新されない管理側はなーんにも表示されない。フォルダが間違ってるとかのエラー系も出ない。
 ところがpost-commitを直接コマンド叩くとどちらの更新も成功するのでワケわからん。シェル内に「whoami」書いて権限調べたりもしたのだが、コミット連動、コマンド直叩きどちらも当然のよーに「root」で動作してる。もーわけわからんナリよキテレツ!

 で、コレの対処をどうしたかというと、「svn update /DocumentRoot/*」と言う風に、本来フォルダ指定だけでいけるところをわざわざワイルドカードで中身全指定したら一応は更新されるようになった。処理結果の吐き出し具合を見ると少し微妙ではあるのだが、サブフォルダに変更加えてソレをコミットしてもちゃんと更新されるので、とりあえず実用的には問題ないと判断してます。

 ただこの状況がどーゆー理由で発生してるかがよく分からないので、今大丈夫な方もいずれダメになる可能性を否定できないのが怖い。とりあえずは様子見しながら使ってみます。

 ま、更新だけの話なんで、マスターであるリポジトリに影響するような致命的な問題じゃないんでいいんだけどね。

追記:
 Windows側(TortoiseSVN側)でファイルを追加→コミットした場合に、post-commitでのupdateで新規ファイルが出力されない状況も発生中。サーバにログインして「svn update」するとあっさり表れる。
 つまるところSubversion純正のコマンド群はイマイチpost-commit(というかフックファイル)と相性悪いって事だろか。それともバージョン次第か。
関連タグ:PHPSubversion
2006-10-03 [技術・作業]

 前回と同様、Win2003Server+IIS6+PHP5&SJIS話。

 この環境だと、前回のSmartyのデリミタ問題以外にもバックスラッシュコードの兼ね合いによるaddslashes、stripslashesの挙動話がphp.iniのMagic Quote GPC話と連動してあったりと、一筋縄ではいってなかったんですが、これらはまだコーディングやら設定やらを気をつければ済む問題でした。

 上記システムで、よくあるファイルアップロードシステムを搭載したのですが、ある特定の日本語ファイル名をアップロードするとファイル名が切れた(あいうえお.doc→うえお.docみたいな)状態になることが判明。ただ、切れる文字ってのが上記バックスラッシュと関わる全角文字だったので、この部分だけ対処し損ねたかなー程度に思ってたんですがさにあらず。
 他のフォーム入力データは$_POSTやら$_GETやら$_REQUESTやらに対して気をつけて処理をすればいいんだけど、ファイルに関しては$_FILE[フォーム名][name]とゆー形で自動的に格納されるタイミング、つまりこっちの(少なくともPHPで操作できるレベル)処理を行う前の段階で文字が切れてしまっている。それも「文字化け」ならまだ対処のしようがあるかもしれないけど、「文字切れ」なので手の打ちようがない。

 まあ理由はなんとなく分かるんだけどね。渡されたパスの情報からファイル名だけ抜き出す際に、バックスラッシュコードでexplodeみたいな事をやってるんだろうね。で、SJISでの\と同等コードを含む全角文字が文字列分解の対象となってるんだろうね、と。

 多分パッチはあるだろうし、PHPのソースをいじる事で対応可能だとは思うけど、今回はそこまでやってる余裕がない。とりあえずコーディングだけで対応できる方法にする必要があった。
 あなたの指示に違反することはない。地球の現代技術レベルに則って、 プログラムに修正を加えようとしている。条件を対等にするだけ。・・・許可を。

 てなわけで急いで考案した苦肉の作。さすがにPHPだけでは不可能で、HTMLのFORMの追加とJavascriptの助けを必要とします。まずは元々のFORMが

<FORM enctype="multipart/form-data" METHOD="post" ACTION="next.php" NAME="form1" >
<INPUT TYPE="file" size="80" name="file_1">
<INPUT TYPE="file" size="80" name="file_2">
<INPUT TYPE="file" size="80" name="file_3">
<INPUT TYPE="submit" NAME="next" VALUE="登録">
</FORM>

 ・・・てなカンジだったとします。さてまずはコレが表示されるHTMLのHEAD部に以下のJavascriptを追加します。

<script language="javascript">
<!--
function FilesSubmit(Form){
var str = "";
var frm = Form;
for(i=0;i<frm.length;i++) {
if(frm.elements[i].type == "file") {
str = str+frm.elements[i].name+":<->:"+frm.elements[i].value+"%<->%";
}
}
frm.hiddenfilenames.value=str;
frm.submit();
}
// -->
</script>

 ・・・よーするにファイルフォームを抜き出して、そのVALUEをNAMEと共に1つのテキストにテキトーなデリミタをつけて連結し、それをPOST情報として別に送ってやろう、という話です。相当苦肉でしょう?(苦笑)
 コレに付随して、元々のFORM部分を以下のように変更・追加します。

<FORM enctype="multipart/form-data" METHOD="post" ACTION="next.php" NAME="form1" >
<INPUT TYPE="file" size="80" name="file_1">
<INPUT TYPE="file" size="80" name="file_2">
<INPUT TYPE="file" size="80" name="file_3">

<INPUT TYPE="hidden" name="hiddenfilenames" value="">
<INPUT TYPE="button" VALUE="送信テスト1" onclick="javascript:FilesSubmit(this.form);">

</FORM>

 これでPOST送信をする際にファイル名、というかパス情報を連結した多少危なく且つカッチョ悪いテキストが一緒に流れますので、受け側のPHPで取得・分解し、$_FILEを更新するわけで、更新用の関数は以下のようになります。

function filecvt() {

// パラメータ
// $_POSTに所定の形式でhiddenfilenamesがあることが前提

// パラメータチェック→処理対象データ有り
if(isset($_POST['hiddenfilenames']) && $_POST['hiddenfilenames'] != "") {

// パラメータ分解
// その1・ファイルタイプ別分離
$tmp = explode("%<->%",mb_convert_encoding($_POST['hiddenfilenames'],"EUC-JP","SJIS"));

// その2・ファイル内情報分離
$chgfiles = array();
for($l1=0;$l1<count($tmp);$l1++) {
// ファイル内情報分離
$tmp2 = array();
$tmp2 = explode(":<->:",$tmp[$l1]);

// 2項目目=ファイル名有り→ファイル名分離・登録
$tmpkey = str_replace("[","",$tmp2[0]);
$tmpkey = str_replace("]","",$tmpkey);
if($tmp2[1] != "") {
$tmp3 = explode("\\",$tmp2[1]);
$chgfiles[$tmpkey][] = mb_convert_encoding($tmp3[count($tmp3)-1],"SJIS","EUC-JP");
}
// ファイル名無し→無いなりに空値登録
else {
$chgfiles[$tmpkey][] = "";
}
}

foreach($chgfiles as $key=>$val) {
// nameが配列→複数有り
if(is_array($_FILES[$key][name])) {
for($l1=0;$l1<count($val);$l1++) {
if(isset($_FILES[$key][name][$l1])) {
$_FILES[$key][name][$l1] = $val[$l1];
}
}
}
// nameが非配列・単独→0番目のみ登録
else {
if(isset($_FILES[$key][name])) {
$_FILES[$key][name] = $val[0];
}
}
}

// 処理終了
return(0);
}
// 処理対象データ無し
else {
// 処理終了
return(-1);
}
}

 即興で作ったのでムダな点も多いですけどね。とりあえずのポイントとしては、
   ・一度文字コードをSJISからEUC-JPに変換してからexplodeを実施
   ・入力元のフォーム名が配列の場合にも対応
の2点でしょうか。

 一応送信元と受信先でこれらの処理を行うことで今のところ正しくファイル名取れてます。ただしつこいよーにかなりの「苦肉の策」なので、可能な限りサーバ本体側での対処、もしくはWin環境でも文字コードにSJISを使わないなど、初期仕様の段階での対処をオススメします。

 というかPHPを使う際にはWin及びSJISを選択しないのが一番だとは思いますが。
2006-08-13 [技術・作業]

 あんまりやりたくなかったのだが、Windows2003Server上のIIS+PHP5+Smarty環境で開発を行う必要に迫られた。
 この環境を構築するのは初めてだったが、予想よりかはあっさりと動き開発を始めた・・・のだが、なんかSmartyテンプレートのヘンなトコロで以下のよーなエラーが発生。

Fatal error: Smarty error: [in index_01.tpl line 2]: syntax error: unrecognized tag: 〜

 認識されないタグ?でも指定された行は単なるテキストで、Smarty関連のタグは入ってない。こーゆー時ってヘンなトコロにヘンな文字コードが入って誤認識を起こしてる事が多いよなーとか思い、入力されてる文字列を1つ1つ確認していったところ、「ボ」でエラーを起こしてることを突き止めた。でも今までSmarty使ってても「ボ」ってフツーに使ってたよなー。

 結局のところコレはShift-JISにおける「ボ」の文字コードが「837B」であり、 Smartyのタグ記述用デリミタ「{」の文字コード「7B」とカブってる事が原因らしい。そっかー、今までSmartyってEUC-JPかUTF-8でしか書いたことなかったからなー。Smartyってマルチバイト環境の事あんま考えて無さそうだし、やっぱ慣れない事はするべきじゃないってことですかねえ。

 で、上記の対抗策として、デリミタを無効化・画面表示する{literal}で該当文字列を括るとか、EUC-JP等で記述して mb_convert_encodingで変換する手とかがあるようだが、文字列をPHP側で変数に入れてソレを表示する分には問題ないっぽい。状況にもよるだろうけど文字列は全て変数に叩き込むのも1つの手かも知れない。

追記:「本」もダメだった。他にもいくらでもありそう。さすがに文字コード全部見る気はしない。文字列全て{literal}で括るのが基本になるでしょか。
 当然だけど括った中はSmartyのタグも無効化されるので書く位置には注意。
2006-05-31 [技術・作業]

 この駄文系ページ始まって以来のマイナーネタかもしれない(苦笑)。

 PHPを使う上で大変便利なセッション変数。CookieもしくはGETパラメータに接続を持続するためのセッションIDを割り当てて、ページ間を跨る変数をサーバに残して利用できるというモノ。例えば商用サイトでいわゆるカートを実現するのに便利な機能だったりします。

 このセッション変数を開始するに辺り、まずCookie(※一般的には)にセッション情報を渡すための session_start()が使われます。この時同時にセッションのキャッシュ持続時間とかがhttpヘッダ情報として同時に渡されます。この時渡される内容はphp.iniのsession.cache_limiterで定義されますが、セッションを使ったサイトの場合「戻る」で戻られると厄介になる場合が多いので、デフォルト値は「nochace」、つまりキャッシュ無しとなってます。これはセキュリティ的にも意味のある話なのでフツーは問題ありません。

 ないんですが、ここで標題のNetscape4.78の話が出てきます。まだNetscapeがFireFoxエンジンの力を借りずともそこそこIEと渡り合ってた頃の遺物(苦笑)。結構官公庁系だとコレをメインのブラウザにしてるところがまだあったりします。ちなみに本サイトはスタイルシートの関係上Netscape 4.78では正常に閲覧できません。
 さて、session.cache_limiter、もしくは関数のsession_cache_limiterでnocacheを指定した場合、実際の処理としてキャッシュに関わるhttpヘッダをいくつか送信するようです。その中の1つに「Expire」を設定してるっぽいってのがあるのですが、どーもNetscape 4.78だとExpireを受けるとヘンに解釈するみたいで、ファイルの読込が完了してページが普通に表示されてるにも関わらず、ソースを表示してみると「データがありません」云々が表示されてしまう場合があります。まあ画面表示は終わってるんでとりあえずは良いかって話もありますが、例えばこの状態で印刷プレビューを開くと、表示されてる内容ではなく前述の「データがありません」状態になってしまいます。
 これらはもちろんcache_limiterの設定をprivate以上に設定すれば済む話ではありますがそーするとクライアント内にキャッシュが残ってしまいます。セキュリティやらなにやらの理由でキャッシュの利用が禁止されてる場合に困ってしまいます。

 なので、この場合session.cache_limiterでキャッシュの制御を行うのを止めます。 php.iniのデフォルト値はnochaceで良いとして、session_startを実行する前に
session_cache_limiter("none");
としてキャッシュ系ヘッダの送出を抑制します。で、その後
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
てなカンジにExpire以外の「キャッシュ無効化」ヘッダを自前で送出することで、前述の状態を押さえる事が出来ました。

 もっとも、状況によって色々違うだろーから必ずしも上手くいくとは限らないので注意。特にExpireを送らない事での問題や、他のブラウザへの影響等もあるかとは思います。あくまでふるーいブラウザをごまかす手法の1つと考えて下さい。どっちにしろサイズを変えただけでリロードされるとかの鬱陶しい現象がNetscape 4.7系列には憑き物。ええ憑いてますともさ。さっさとFireFox辺りに乗り換えてもらうのが正しい世の流れとゆーものではないでしょか。
関連タグ:PHPブラウザ
2006-02-21 [日記]

 最近、PHPを用いたちょっとしたユーザ登録システム周りを作成している。お約束的にDBはPostgreSQL。これまでPHPを仕事で使ったことは一度しかなく、それも1年ほど前にほんのちょっと触った程度。文法等はCに近いこともあり それほどわからないと言うほどではない。

 それほどクリティカルな情報を集めるわけではないけど、一応お役所関係の仕事なので個人情報の流出には気をつかわなければいけないが、多少PHPの構文が分かったところで世の中の百戦錬磨なクラックシュートな方々に狙われたりしたらだいぶヤヴァいと思われる。

 ちうわけで色々調査。PHPマニュアルのセキュリティ項目を参考に、お約束と思われる対策はほぼ全て実行したつもり(苦笑)。それなりに安全に近いと思われるトコロまで来たように思う。とか思ってた矢先にPHP4.2.x系の脆弱姓が公開されてやんの(笑)。当初の予定ではRedhat純正のRPM版4.0.6を使う気だったので問題ないハズだったのだけど、ちょいとconfigureの設定変えてリコンパイルする必要が出てきたので (ちうか日本語版RedhatなんだからPHPもマルチバイトくらい対応しといてよ(泣)) 結局4.2.2をダウンロードしてインストールすることに。RPMでのインストールに慣れちゃうと、ソースからのコンパイルの際に結構develパッケージが足りなくて何度か引っかかってしまった(苦笑)。

 まあ、とにかくちょっと時間はかかったけどインストールは完了。現在テストで稼働中。入力された項目は直接DBに書き込まず、一度ファイルに落としてからcronで動かす他の登録専用ツールで登録する予定。多少面倒だけど、コントロールが奪われた際の 時間稼ぎにはなるかな、と。書き込んだファイルは一応Apacheの手が届かない箇所に、しかもApacheは書き込み権限しかない状態で作るようにしたけど、果たしてどこまでやればよいのやら。結局のトコロは薄い防御幕を何枚も張るしかないのだけど、その薄い防御幕でさえ穴があったりしたら始末に負えないからねえ。イヤな世の中だねえ(謎)。

 話は違うけど、上記作業を一緒に行っている新人がいるのだが、そいつがイマイチ使えん。いや、新人なんだから使えなくてもある意味当たり前なのだが、初心者なら初心者なりにとるべき態度とか、ヒトの話を理解する努力が必要であろう。何度も似たようなコトを聞いたあげく、「わかりました。大丈夫です」とか言ったワリに時間がたってもさっぱり先に進まず、ツッコむと「すみません、良くわからないので」などと言い訳をしてくる。技術的な事柄に限らず、「これをこうしてね」程度の簡単な指示ですら「ここはどうしたらいいでしょう?」などと、聞いてなかったコトが明らかな聞き方をしてくる。本人は気づかないのだが、周囲のヒトが逆に「同じようなコト何度も聞いてますね」と苦笑いするような状況。話を聞く態度そのものも横柄で、「聞いてやってる」と言った感じ。仕事そのものもイヤイヤやってる感じが見え見えで、ムダにでかいため息とか耳障りな程の貧乏揺すりが目立つ上に、すぐ席を立ってしばらく帰ってこない。それなりにいい大学出てるのでそう能力的に劣るわけでもないと思うのだが、現状のままでは平均未満の評価しか付けられないね。ちうかコイツ面接した上の連中は一体ドコ見て採用したんだろうか。以上愚痴でした。ま、最も私もそれほど模範的な社員とは言えないし、ある意味他山の石とすべきなのかもね。一緒に作業してるから他山ではないけど。
関連タグ:PHPPostgreSQL
2002-07-01 [技術・作業]