基礎力の違いなのかなぁ…

http://phpspot.org/blog/archives/2008/01/php_89.html
経由
http://ke-tai.org/blog/2007/12/12/php_session_new/
んと…多分、Blogの内容日付からして、年単位でやってるんじゃないかなぁ多分、と思われるです。
まぁ内容的に、ほかのところよりはよいと思うのですが*1。

それなりの出来であるだけについ欲を出してしまうのが、ここ。
http://hidenov.blog4.fc2.com/blog-entry-182.html
http://hidenov.blog4.fc2.com/blog-entry-185.html
三日と一週間でそれぞれそこにたどりつきますかねあなたは orz

んと…多分じゃなくて確定で「このWebアプリケーションの危険性に気が付いたのもＣ言語で実際にHTTPのクライアントなりサーバなりを実装した経験があるから」というあたりに集約されるのですが。
やっぱりこの辺のごりごりんとした基礎が出来てないと駄目なのかなぁ…とか一瞬悩んでしまうです。

先人に曰く「出来なきゃやれ」。「今」出来ないんなら、出来るようにがんばりましょう学びましょうプログラム組みましょうデバッグしましょう。
………さて、がんばってC言語講座書かなきゃ orz

*1:セッションハイジャックについて一応ふれている点とかsession_regenerate_id関数について書いてある点とか

デバッグ用簡単プログラム

最近文字コード関連で頭痛多すぎるので。ちとdumpもどきつくりました。

static public function dump_string(&$s)
{
  $len = strlen($s);
  $ret = $s . '(';
  for($i = 0; $i < $len; $i ++) {
    $ret .= sprintf("(%02x)", ord($s[$i]));
  }
  $ret .= ')';
  return $ret;
}

static functionなのは「ぢつはclassの１メソッド」なのと。
引数が明示的に参照なのは「おっかない文字列をしゃれにならないcopyされたくない」からです(PHPでちゃんといけるのか微妙なのと、本当はconst修飾子つけたくてたまらんのですが)。

限りなくアバウトですが、デバッグの一助程度にはなろうかと(なにせこの子が入ってる元々のクラス名「debug_util」ですから)。

「縛らない」という縛り方

ちとあちこちを見ての雑感。

えと…純粋な好みの問題で、男女間を例題に(笑
例えばどんなにいい女だとしても。「あたしだけを見てね」と四六時中言われると「絶対にあたしのところに帰ってきてね」と散々言われると。まず間違いなく男は逃げます*1。
でも大抵の場合「縛れば逃げない」と考えるのが世の常です。んでもって結果的に「妙に縛りがきつくなり」「それでも逃げられる」例は…それこそ八百万(やおよろず)です。

ここで、ごく少数が。「ああ好きにしてあたしは縛らないから戻ってきたかったら戻ってきてもいいわよ別にあたしは待ってないから」と言われると。
その居心地のよさと適度な自由さにぐらっとくる御仁は少なくないと思われます。
でも実際問題「本当にあちこちふらつき続けるほどの体力や精神力」なんて人間にはないものなので。結果的に「好きにしていいよ」といわれたところに落ち着いてしまうこともまた多々。

多分一番怖いのが「わかってて」縛らない人とか会社とかその他(笑
そーゆーのを本当の意味で「悪女」といいます B-P
ま。「わかってて」手玉に取られるなら、それはそれで楽しいと思いません？

ま…これ読んで実行できるくらいの度量があるなら初めから縛ろうとは思わないのかもしれませんが B-P
# 寝てないのでちょっと黒いネタｗ

*1:この意味合いにおいて。岩崎宏美の「家路」はすばらしき歌詞です B-P

雑感二種

いち。「初心者にもわかるように教えてください」は多分無理。
わりとあちこちで見る字面なのですが。んと…なんていうか…「小学生に複素数平面をわかりやすく説明してください」とかいうのと大してかわらない気がする。
知るためには「ある程度の」前提条件が必須なので、その前提条件を満たしてなければ、おそらくは「理解させるのはまず無理」だと思う。
多分「無理である事さえもわからない」程度に無知なのだろうとは思うのですが*1。
問題は「無知の無知であることを理解させる」方法が思いつかない事くらいでしょうか orz

に。「勝敗条件は人それぞれ状況次第」。
この話を書こうと思ったのが陣内さんの格差婚の話だったりするとかいう余談はおいといて B-P
あちこちで、勝っただ負けただ成功だ失敗だと「他人の行為に対して」色々なランク付けが行われているですが。本質的に、勝敗だの成否だのの条件は人それぞれで、場合によっては「他人には計り知れない部分がある」事を忘れちゃいけない。
…っていう話は、TRPGというゲームをある程度深くやってると割と容易にわかりそうなものなのですが。通常のゲームの多くが「明確な勝者と敗者を生む構図」になりやすいので、その辺が一つ勘違いしやすい原因なのかなぁと。
多分重要なのは勝つ事や負ける事や成功する事や失敗する事ではなくて。「自分が何をどうしたくて」「その目標に対して実際はどんな感じだったのか」と。そこが明確なら得るものもあるでしょうし、明確でなければ他人に振り回されて終わるでしょうし。
っつか。勝利条件が明示されていなければ(っていうか自分で作れるなら)、勝敗は自由自在なので。その時点で多分、勝敗にこだわる理由すらなくなる。
っていうかピ〜の笛。…彼らの勝利条件はどの辺にあるんでしょうか？ いわゆる一般的(かどうかは知らない。もしかすると理想的、なのかもしれない)スポーツマンシップとは大分に遠いところにありそうなのですが。

*1:この辺いわゆる「無知の無知」というやつですね

複数のSSL証明書

んと。直近に発生してたのが

• １台のマシンでってつまりひとつのIPで
• 複数のサービスを、各々違うドメインで動かしてて
• それらにSSLを導入したい

って話ざんした。

まぁ名前ベースのVirtualな設定にSSLの設定もぐりこませりゃいいや証明書はそれぞれ買うとして。

はいダウト。
うん冷静に考えればNGなことわかるのに、ついうっかりさんしてしまいました久しぶりに*1。

一応おさらい。
SSLは「通信を暗号化して」やり取りするです。
…ってとこで冷静に考えると。いわゆる「個人情報をやり取りするのにhttpsぢゃないなんて…」って発言は前提として「パケットがスニったりフったりできる」って事なんだろうかなぁとおもうとちと怖いのですが色々と。

おいといて。

一方で。VirtualHostとかあのあたりの機構は、HTTPヘッダ内にあるhostとかいうものの中にあるドメイン名から判定をするです。

HTTPヘッダの中を見ないと鍵がない。
鍵がないとHTTPヘッダが見れない。

かくして人類は迷宮でミノタウロスに…テセウスの一撃を食らわせることなく迷い死ぬです。たどるべき麻糸もないことですし。
…ってしなれても困るので、せめて麻糸くらいは。

ひとつは「おとなしくIPベースにする」です。問題は、昨今枯渇問題が騒がれて久しいIPをそこまで浪費してよいのやら。
もうひとつは「待ち受けポートを変える」。わりと現実的。URIにポート番号がつくくらいはご愛嬌ってことで。
ただ、携帯系だと、SoftBank系がこれに非対応っぽいので、これもまた憂慮すべき事柄。

ついでに余談。
apachectlでgracefulをよく使うと思うですが(ってか使え)。
普段だと、たとえSSLなapacheでもパスフレーズ不要で便利なのですが。SSL証明書追加したときにこれやると「問答無用でパスフレーズ失敗」とみなされるっぽいです。
おとなしくあきらめて、restartなりstop ＆ startなりしませう。

以上微妙な覚書。

翌日追記
ふっふっふ…DoCoMo系公式サイトにて。uidの解決(NULLGWDOCOMOってやつね)しやがらねぇ orz
この辺考えるとEZが一番扱いやすいのかなぁ？ 証明書買わなきゃいけないけど orz

さらに追記。
………EZ、port指定すると403エラーではねるっぽ orz
そりゃそうだよねぇ考えてみればdomain違う証明書でNG出すキャリアだもんねぇってか証明書でドメイン齟齬はわかるけどport番号指定は別にいいと思うんだけどなぁ orz

*1:久しぶり？とかいう突っ込みはおいちゃん嫌いだな。

ぢゃんくな話

「おいしいハンバーガーのこわい話」っていう書籍があるです。

おいしいハンバーガーのこわい話

キッチンで働く人は、工場の組み立てラインで働く行員みたいに、単純な作業を一日中繰り返すのだ。
-中略-
腕のいいコックはもはや必要なかった。ここで働く人間は、たくさんの作業を覚えなくていい。覚えるのは、ひとつだけ。こういう仕事なら、人を雇ったりクビにしたりしやすいし、払う給料も少なくてすむ。

ふたりがのちに出した広告では、店の経営者にとって都合のいい点がこんなふうに説明されている。

ファストフード業界では、長く働き続けて賃金が上がった少数の腕のいい従業員より、低い賃金でも喜んで働く未熟なパートタイムの従業員をもとめている。

働く時間が長く、賃金は低く、医療保険もなく、きびしい規則につねに従わなくてはならない、というわけで、ファストフードの仕事の評判はよくない。その証拠に、内容がつまらなくて、賃金が低くて、手に職が就かない仕事は“マックジョブ”と呼ばれている。

ほかにも色々と山盛りてんこ盛りに書かれているのですが。
………おかしいなぁファストフード業界になんて勤めていないはずなのに、なぜかしら、とても嫌な親近感というか嫌悪感を感じる。
定型化して素人にマニュアル通りに物事をやらせれば、彼らのいろいろなモノと引き替えに、経営者はうはうはのウマウマで濡れ手に粟な感じになるはずなのに。
「氷とクリームとイチゴ、砂糖にバニラ少々」で作るよりも「乳脂肪＋脱脂乳、砂糖、スイートホエイ、高果糖コーンシロップ、グアルゴム、モノジグリセリド、セルロースガム、リン酸ナトリウム、カラギーナン、クエン酸、食用赤色40号に加えて、何十種類もの化学物質で合成された人工苺香料」で作る方が安上がりなはずなのに。…中身を知らなければね(でもどうせ中身なんて誰も見ないし興味も持たないでしょ？)

多分そこに残るのは。使い捨てにされたもう動かない人形達と、イナゴの大群によって食い尽くされ荒されきった不毛の土地、なんだろうなぁと。

知らない事見ない事ってのは、思った以上に怖くて、思った以上に破壊力があるのかなぁとふと思ってしまったので、雑記。

なぜ事前処理したがるのだろう？

直近には、これ。
http://blog.livedoor.jp/dankogai/archives/50979976.html

入力を検証せよ(Validate input) - 信頼なきデータソースからの入力は、全て検証するようにしましょう。適切な入力検証は、大部分のソフトウェア脆弱性を取り除きます。外部データは疑って掛かりましょう。これらにはコマンドライン引数、ネットワークインターフェース、環境変数、そしてユーザーの管理下にあるファイルが含まれます [Seacord 05]。

んと………なぜ？
或いは「検証って具体的にはなにをどうするの？」 ← 多分一番疑問なのはここ。

いわゆる「悪意あるデータ」については

他のシステムに送るデータは消毒(サニタイズ)しておけ(Sanitize data sent to other systems) - サブシステムに送るデータは、消毒しておきましょう[C STR02-A]。コマンドシェルやリレーショナルデータベースや商用のコンポーネント(COTS)などが相当します。攻撃者は、SQLやコマンドなど、インジェクションを用いてこれらのサブシステムを攻撃することが出来ます。これは入力検証の問題に限りません。なぜならそこで呼び出されるサブシステムが、何のためにそのコンテキストが呼び出されるか理解しているとは限らないからです。コンテキストの解釈は呼び出し側が担っている以上、データを消毒しておく責任も呼び出し側のシステムにあります。

これで足りるんじゃないの？ と思ってしまうんですがどんなもんなんでしょ？

結構あちこちで絶賛されてるだけに…正直、山盛り疑問です。
とりあえず…コメントでの突っ込みに期待、かな？