上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

IE8と色々と… [2009/03/29 (日)]

IE8正式版を一週間ほど使ってみた。う~ん…
実にいい!…けど、一点だけ、とても気になる部分がある。

まず凄く改善した点、CSS2.1への標準準拠度が格段に向上した。多分、Gecko1.9よりバグ少ないかも…と思う。(ちなみにレンダリングエンジンのバグの少なさで言うとAppleWebKitがたぶん一番)。新機能のアクセラレータとかWebSliceも結構使える…気がするし。

まぁそんな憎らしい位に素晴らしいIE8なんだけど、実はちょっとびっくりした点がある。それはおいらのこのブログのテンプレート。IE8で治る予定だった表示の不具合が幾つかあったんだけど治ってない。何故?と思い調べたら、MSのサーバがIE7用に作られたサイトを公開していてどうやらそのリストに入っている。もち、こんなまばらしか人の来ないブログを天下のMicrosoftが見ている分けではない。fc2.comのサブドメインに入ってるのが原因らしい。(res://iecompat.dll/iecompatdata.xmlとアドレス欄に打つとMSのサーバから取得したリストが表示される)。これを何とかするには、metaタグでX-UA-Compatibleを指定するらしいんだけど…。

思うに…ちょっと前までWebは、ブラウザと欲しいページのサーバその1対1の関係が基本だった。この独立した単純さで誰でもコンテンツを発信出来るのが草の根的なWebの魅力だとおいらは思う。けどフィッシング詐欺やらピンクサイトやらが増えて、そのフィルタリングが重要になってきてそうも行かなくなた。で、そうしたヤバ目のページのリストを管理用のサーバからもらうようになった。そこまではいい、全然構わない。けど、今回ついにおいらのページまでMSの中央のサーバの影響を受けるようになってしまった。

で、だから?どーこーと言うわけじゃないんだけど!気分的にね…
「ほっといてくれ、ばかやろー」って言いたい。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

スポンサーサイト
まず、基礎知識、Javaのセキュリティのお話。

複数のプログラムを協調動作させる場合、単体プログラムを動かす場合と違ってちょっと特殊なセキュリティの問題がある。単体の場合、とても単純。書いた人が信用できるなら、そのプログラムに何でも出来るように権限を与えて動かせばいい。もし信用できないなら、パソコン上の重要なファイル等は読み書きさせないように制限すればいい。これが複数になると事はこう単純には行かなくなる。例えば、信用ある会社の書いたプログラム S(safety) がダウンロードしたネット上のどっかの誰かが書いたプログラム W(worning) と協調動作する場合を考える。

W 内からは重要な資源にアクセス出来なくする。(失敗)
この方法はWがSを呼び、Sに重要な資源にアクセスさせる可能性がある。 Sがそのような資源にアクセスするかは、Sが複雑なプログラムだった場合、W から S への呼び出しを見張るだけでは判断できないため、この方法は使えない。

ここでのセキュリティの破り方は誰か権限のある人に悪さをしてもらう構図。…まるで政治家と企業の癒着のよう…。お金の流れが複雑になると、献金の種類等で単純に規制してもうまくいきにくい所も似ている…。けど!Javaはもっとかしこい…振り込まれた口座から資金の出所を確認するまでいちいち一つ一つ追いかける…マルサのJava!! つまり、スタックトレースを調べ上げ (もしくはそれと同等の事をし)、呼び出しの背後関係を洗い出し、その中に一つでも怪しいプログラムがあればエラーにする。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

続きを読む »

インチキSerializable [2009/03/01 (日)]

…前回の記事の追記に、、、間違い発見!!TypedKeyimplements Serializableとあるけど、同一性の判定がリファレンス判定(==演算子)だから、シリアライズ前後で同一性が崩れる。普通のクラスならこれでいいんだけど、キー専用クラスでこれはひどい。しかも、finalになってるからequalsメソッドのオーバライドのしようがない。

で、解決策を考えたんだけども…あんましいー案が無い…。final取って、デシリアライズ時に前と同じインスタンスの作り方をするよう個々のメソッドをオーバライドする事を考えたんだけど…。楽しようとしてそれを匿名クラスでやろうとすると、Javaの仕様的にまずい事になる*1。つまり、いちいちstaticクラス(内部クラスも可)を宣言して、SerialVersionUIDをつけて…ん?もうデシリアライズ用のメソッドいらないか、、、でもどのみち面倒…。もうぶっちゃけ振り出しに戻ってStringでいいかも…とも思うけどでもそれはそれでちょい危険だし、、、う~ん…。


さてさて!!、日本のいい言葉に、「我が振り見て人の振り直せ」という言葉がある。これは自分が失敗した時には、同じ失敗をしている人を見つけて、その人の失敗を指摘してる間に自分の失敗をうやむやにしてしまおうという、素ん晴らしい言葉だ。そう、おいら以外にもインチキSerializableを作っているライブラリを発見!!

Commons FileUpload (お世話になっております) のDiskFileItemクラスがそれだ。ファイルアップロードの場面で確認画面とかを出そうと思ったら一旦ファイルをセッションやらDB側で保存しないといけない。しかも、ユーザは結局そのファイルを使わずどっか行ってしまうかもしれない。そうなるといつ消されるとも分からないファイルが残る。セッション破棄イベントでそれらを消すにしても、ドSなユーザがファイルを沢山アップロードをしたらば、もうお終いになる。(量に制限をかけて、古いファイルを消す手もあるけど、ユーザ数が多すぎてセッション自体を使いたくない場合は本当にお手上げ) と、まぁそんなこんなで、ファイルデータの入ったDiskFileItemをビューステートに入れといてサーバリソースを節約しようとしたら、悲劇! 一時ファイルが読めない!Servletスレッドが終了したら、どっかのタイミングで一時ファイルが消されるらしい。

…まぁ当然と言えば当然なんだけど。なんでこんな当たり前に気づかなかったかと言うと、ドキュメントにimplements Serializableってあったから。そう、ドラマで言うなら、「何か変だと思ったけど信じたの!」 「できないなら最初っから出来ないって言えばいいじゃない!」 「何でウソつくの!?」 「もーいい!自分でやるわ!」 って展開の主人公になる…そうちょっと理不尽。 …ま、…おいらのケースよりはいく分ましだけど…。:-P)

*1
匿名クラスの名前の付け方はコンパイラによって違い、さらにstaticフィールドを付けられないので、serialVersionUIDも宣言できない。これではクラスの特定が出来なくなる。ちなみに、ローカルクラスと非static内部クラスも親クラスインスタンスへの暗黙フィールドの名前の付け方がコンパイラによって差があってシリアライズの障害になる。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。