« February 2008 | Main | April 2008 »
March 31, 2008
Adobe AIR for Linux アルファ版リリース
Adobe AIR の Linux 用アルファ版がリリースされました。（Adobe AIR for Linux@Labs） アルファ版ですのでまだバグもたくさんあると思いますがよろしければお試しください。Mac 版 Win 版と同様に英語版になります。
サポートされる環境は以下のとおりです。
Linux Distribution：
- RedHat Desktop Linux 4
- RedHat Enterprise Linux v5
- Novell Desktop Linux 9
- SUSE Linux Enterprise Desktop 10
- Ubuntu 6.06
デスクトップ環境：
- GNOME
- KDE
パッケージ管理：
- RPM
- Debian
ウインドウマネージャ：
- Metacity (default for GNOME)
- KWin (default for KDE)
その他詳細はリリースノート （英文） をご覧ください。Linux 版の日本語版に対する要望があれば是非お知らせください。
Posted by ackie at 07:20 PM | Comments (0)
March 26, 2008
Flash オーサリングのセキュリティ情報
Flash CS3 および Flash 8 関連のセキュリティ情報が公開されました。（Flash CS3 Professional、Flash Professional 8およびFlash Basic 8における潜在的な脆弱性）
Windows 版に fla ファイルを利用した攻撃に悪用できる脆弱性が見つかったという報告です。怪しい fla ファイルを受け取ったら開かないよう注意してください。この問題は時期メジャーリリースで修正予定とのことです。
Posted by ackie at 06:15 PM | Comments (0)
March 17, 2008
ソケットポリシーファイルと Flash Player セキュリティ
ソケットポリシーについて書こうと思っていたら既にちゃんとした記事が公開されていました。
ので、ここではごく簡単に。
ソケットポリシーファイルは Flash Player 7 の時に導入された機能で、XMLSocket や Socket を使った接続要求に対して、サーバ側でアクセス制御を行うための手段として使用されます。
ソケット経由の接続ポリシーに関して Flash Player 9.0.115.0 から変更された主要な点は、１．マスターポリシーファイルの導入、２．メタポリシーのサポート、３．より厳格なソケットポリシーの採用です。9.0.115.0 では、これらを満たしていない環境を警告として扱いますが （デバッグプレーヤだと警告メッセージをログにを出力できます） 来月のアップデート版以降はエラーとして扱うようになります。
とりあえず対処するには、以下のような内容を TCP のポート 843 から返すプログラムをサーバ上で実行します。allow-access-from タグ内の domain と to-ports 属性には実際の環境に合わせて適当な値を設定してください。
<cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain="mysite.com" to-ports="999,3050-3052/> </cross-domain-policy>
さて、以下もう少しだけ詳しい説明です。
ソケットマスターポリシーファイル
接続にもマスターポリシーファイルのコンセプトが導入されました。HTTP 接続のマスターポリシーファイルは /crossdomain.xml ですが、ソケットマスターポリシーファイルは TCP のポート 843 から送られるポリシーファイルということになっています。
1024 以下の固定のポート番号を使用することで、ポリシーファイルの管理を、適切な権限を持つ管理者が標準化された方法で行えるようにしたいというのが意図のようです。なお、ポート 843 の使用に関しては現在 IANA に申請中とのことです。
ソケットメタポリシー
ソケットメタポリシーはソケットポリシーファイルの使用条件を設定するためのもので、マスターポリシーファイルのみに指定できます。このメタポリシーの利用もソケットマスターポリシーファイルが採用された理由の一つです。
メタポリシーの種類は以下の 3 つです。
- all：ポリシーファイルをどのポートからも提供可能 （データを一般に公開しているサーバ向け）
- master-only：ポート 843 からのみポリシーファイルの送信を許可
- none：ポリシーファイルを不使用に （Flash Player からの接続を一切許可しない）
デフォルトのソケットメタポリシーは all です。
強化されたソケットポリシー
9.0.115.0 以降 Flash Player からソケット接続をするには、個々の接続が明示的にソケットポリシーファイルにより許可される必要があります。（前述のように 9.0.115.0 では警告扱いです）
Posted by ackie at 09:13 PM | Comments (0)
March 12, 2008
メタポリシーを使った Flash Player セキュリティ管理
メタポリシーは、昨年 12 月に発表された Flash Player セキュリティ関連の変更点のひとつです。 メタポリシーに間しては 4 月のセキュリティアップデートでの変更が行われないため、まだ対応しなくても直ぐに問題になることはありませんが、いずれ必須になることは明言されていますので早めに対応しておいたほうがよいかと思います。
さて、メタポリシーはサイト管理者がポリシーファイルを管理するための手段として提供されています。たとえば、管理者の知らないところで勝手にポリシーファイルを定義してアクセス許可を与えるといった状況を防ぐのに使えます。
メタポリシーはマスターポリシーファイル内に記することができます。マスターポリシーファイルはサイトのルートに置かれたポリシーファイル （/crossdomain.xml） です。マスターポリシーファイル内には今までどおり通常のポリシーも記述することができます。メタポリシーの記述には site-control タグを使用します。下はマスターポリシーファイルの例です。
<?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <site-control permitted-cross-domain-policies="all" /> <allow-access-from domain="*" /> </cross-domain-policy>
誰でも自由にすべてのリソースにアクセスできるサイトであれば上の内容をそのまま使えばメタポリシーへの対応は完了です。とりあえず対応だけはしておこうという場合も、上のようにメタポリシーとして all を指定しておけば、将来 Flash Player がこの件でアップデートされても影響を受けません。
all を含め、メタポリシーとして指定できる値は 6 つあります。
- all :
全てのポリシーファイルを許可 - by-content-type :
Content-Type が text/x-cross-domain-policy のポリシーファイルを許可 - by-ftp-filename :
FTP サーバから crossdomain.xml という名前のポリシーファイルのみ許可 - master-only :
マスターポリシーファイルのみ許可 - none :
全てのポリシーファイルを不許可 - none-this-response :
特定のレスポンスでポリシーファイルを不許可
メタポリシーを指定するもうひとつの方法は HTTP ヘッダに記述することです。特に、上のリスト内の最後の none-this-response だけは、HTTP のレスポンスヘッダにしか記述できません。また、HTTP ヘッダを使用するときには none-this-response を除き全てのレスポンスに同じポリシーを指定する必要があります。下はその例です。
HTTP/1.1 200 OK X-Permitted-Cross-Domain-Policies: none
HTTP レスポンスヘッダー内の値はマスターポリシーファイル内の値よりも優先されます。
Posted by ackie at 06:07 PM | Comments (0)
March 11, 2008
来月 （2008/4） の Flash Player セキュリティアップデート
Flash Player のセキュリティアップデートが来月予定されている旨の情報が US のサイトに公開されました。（Preparing for the Flash Player 9 April 2008 Security Update）
このアップデートは純粋にセキュリティ改善を目的としたもので、新機能は一切ありません。しかし、デフォルトポリシーの変更などが行われるため、既存のコンテンツの中には動かなくなるものが出てくることも予想されます。
今回、事前に情報が公開されたのは、この変更に事前に準備する期間を確保するためです。以下、変更点の概要を説明しますので、影響を受けると思われるコンテンツがある場合は対応をご検討ください。
1. javascript のプロトコルとしての利用
これまでは loadMovie() メソッド等と使用して javascript を呼び出すことが可能でした。今度のアップデート以降は、getURL() か navigateToURL() または ExternalInterface のみで使用できるようになります。
2. allowScriptAccess の扱い
allowScriptAccess は swf からスクリプトへのアクセスを制御するための HTML タグに指定する属性です。既存のプレーやでは swf 7 以前のバージョンの swf に対しては allowScriptAccess = always が、 swf 8 以降のバージョンの swf に対しては allowScriptAccess = sameDomain がデフォルト値でした。
今後はすべてのバージョンの swf に対して sameDomain がデフォルトになります。そのため、swf 7 以前のバージョンでパブリッシュされた swf はスクリプトの呼び出しができなくなるケースがあります。その場合には、明示的に allowScriptAccess = always を指定してください。
3. HTTP ヘッダへの追加
XML.addRequestHeader()、 LoadVars.addRequestHeader()、 URLRequest.requestHeaders を利用すると、HTTP リクエストを送る際にヘッダに属性を追加することができます。ここに、新しいプレーヤからは、他のドメインのサーバにヘッダを追加して送信する際に、まず送り先のサイトの許可を確認するという動きが追加されます。
具体的には、受け側のサーバ上の crossdomain.xml に以下のようなエントリが必要になります。
<allow-http-request-headers-from domain="www.example.com" headers="HeaderName"/>
4. ソケット接続時のポリシーファイルが必須に
XMLSocket や Socket を使い接続をする際のポリシーファイルの条件が厳しくなります。アップデート後からは同じドメイン間の接続でも、個々の接続用またはポート 843 を介したマスターポリシーファイルが必要になります。
ソケットポリシーファイルについてはまた別の機会にもうちょっと詳しく説明したいと思います。
とりあえず今回は以上ですが、将来的にはメタポリシーの使用に関する変更があることなども既に発表されています。現在動いていても将来変更が必要な設定については、セキュリティログ （「Flash Player 9.0.115.0 セキュリティポリシー変更について」 内ログファイルの項参照） に警告として出力されるはずですので、サイトを管理されている方は一度確認してみることをお勧めします。
Posted by ackie at 05:17 PM | Comments (0)
March 10, 2008
BlazeDS のプッシュ機能（その３）
ちょっと間が空きましたが、BlazeDS を使ったサーバからのプッシュ 3 つ目の方法です。
３．Polling + Piggybacking （使用するチャネル： AMFChannel）
この方法は、昔ながらのポーリングをベースにしています。基本的には、サーバにデータの有無を確認するポーリングリクエストを定期的に繰り返し送信することでサーバから最新の情報を取得します。
それに加えて、ポーリング以外のタイミングでサーバへのリクエストを送信する際にも、そのリクエストにポーリングリクエストを付加して送信します。するとサーバは元々のリクエストに対するレスポンスに加えて、ポーリングへのレスポンスがあればそれも一緒に返します。（このように抱き合わせで送信することを指してピギーバックと呼んでいます）
さて、ポーリング＋ピギーバッキングの設定例です。
<channel-definition id="polling-piggybacking-amf" class="mx.messaging.channels.AMFChannel"> <properties> <polling-enabled>true</polling-enabled> <polling-interval-millis>10000</polling-interval-millis> <piggybacking-enabled>true</piggybacking-enabled> ...
ロングポーリングのときと同様に polling-enabled を true にしてポーリング機能を有効にします。そして、polling-interval-millis には 10000 を設定しています。これは 10 秒間隔でポーリングリクエストを送信するようにという指定です。
polling-interval-millis の値を小さくするほどリアルタイム度が高くなります。（ロングポーリングでは 0 でした） が、その分余計なオーバヘッドが発生しますし、無駄なリクエストの数も増える可能性があります。この方法はせいぜい数秒に一度情報が更新されれば大丈夫といった使い方が向いていそうです。
ロングポーリングの例と違い、上のサンプルでは wait-interval-millis を明示的に指定していません。サーバ側はリクエストを受けたら直ぐに返信するという動きにしたいので、デフォルト値 （0） から変更する必要が無いためです。
あとは、piggybacking-enabled を true にしておくことで定期的なポーリング以外のタイミングでも情報を受け取れるようになります。効果の程は、どのくらいアクティブにクライアント側でのインタラクションが行われるかによりそうですね。
この方法は、前の 2 つの方法と違ってサーバのスレッドをブロックする必要がありません。そのため、スケーラビリティの面からは有利だと考えられます。とはいえ、サーバ一台辺りが処理できる数は数百のオーダーだと思われるので、よりスケーラビリティの必要な環境では BlazeDS の代わりに LCDS の利用も検討してみてください。
最後に、この方法に限らず、サーバからのプッシュと RPC に個別のチャネルを使用する必要はありません。効率的なリソース使用の観点からは一つの ChannelSet で RPC やサーバからのプッシュやデータ管理用コンポーネント全てをまかなうようにすることをお勧めします。
Posted by ackie at 09:57 AM | Comments (0)
March 04, 2008
BlazeDS のプッシュ機能（その２）
引き続き BlazeDS を使ったサーバからのプッシュ機能の設定のご紹介です。
２．ストリーミングチャネルの使用 （使用するチャネル： StreamingAMFChannel）
この方法では、クライアントが HTTP リクエストをサーバに送ってクライアント・サーバ間の接続を確立すると、サーバはその接続をデータプッシュ専用のチャネルとして張りっぱなしにします。サーバからのデータは HTTP 1.1 の Transfer-Encoding: chunked を使って送信されます。（そのため HTTP 1.0 クライアントはこの方法が使えません）
ロングポーリングではサーバがデータをプッシュする度にクライアントは新しいポーリングリクエストを送りなおす必要がありましたが、ストリーミングチャネルでは一度リクエストが送られると後はサーバからのプッシュのみ繰り返しになります。ポーリングによるオーバヘッドが無いことや、より遅延の少ないデータ配信が可能であることはこの方法の利点と考えられるでしょう。
下はストリーミングチャネルの設定例です。
<channel-definition id="my-streaming-amf" class="mx.messaging.channels.StreamingAMFChannel"> <properties> <idle-timeout-minutes>0</idle-timeout-minutes> <max-streaming-clients>100</max-streaming-clients> <server-to-client-heartbeat-millis>5000</server-to-client-heartbeatmillis> ...
idle-timeout-minutes に 0 を指定するとチャネルがタイムアウトにより閉じられることがなくなります。これで、ずっとチャネルを開きっぱなしの状態が実現されます。
ストリーミングチャネルも接続されているクライアントの数だけサーバのスレッドを占有します。そのため max-streaming-clients を使ってストリーミング用に使用できるスレッドの最大数を指定するようにします。上の例では 100 が設定されています。
貴重なスレッドを不要なのにも関わらず使用していたら効率がよくありません。そのため、サーバからクライアントがちゃんと接続されているか確認信号を送ることができるようになっています。server-to-client-heartbeat-millis に正の値 （単位はミリ秒） を指定するとこの機能が利用できます。上の設定では 5 秒おきにハートビートが送信されます。
ところで、ストリーミングチャネルでは、一回のリクエストに対して複数回に渡りレスポンスを送るという構造になるため、サーバとクライアント間のネットワーク構成の影響を受ける可能性があります。例えば、間の HTTP プロキシがデータをバッファしてからクライアントに送るような環境では、リアルタイムのプッシュが実現できません。
そのため、idle-timeout-minutes には 0 でなく 2 や 3 （単位は分） を指定して、「データは送られているがクライアントには届いていない状況」を判別できるようにしたほうが安全だと考えることができます。その場合は、クライアント側では「届いていないと判断されてチャネルが閉じられてしまった場合」に備えて、ChannelSet に 2 次利用できるチャネル （ポーリング AMF チャネル等） を指定しておく必要がありそうです。
このようにストリーミングチャネルは動きに少し癖があります。最初にご紹介したロングポーリングの方が一般的には使いやすいかもしれませんね。
3 つめの方法は、また次回。
Posted by ackie at 07:55 PM | Comments (0)
March 03, 2008
BlazeDS のプッシュ機能
Flex 3 と一緒に BlazeDS がオープンソースプロジェクトとしてリリースされました。BlazeDS は RPC とサーバからのプッシュを実現するためのサーバ側のテクノロジーです。クライアント側は Flex 3 のライブラリを使用します。
BlazeDS のプロジェクトサイト（http://opensource.adobe.com/wiki/display/blazeds/BlazeDS） には GNU LGPL 下で turnkey （Tomcat 付き構成済みバイナリ）、バイナリ、ソースの 3 種類のリリースバージョンが公開されています。
また、Adobe のバグ管理サイトにも BlazeDS 用のバグデータベースが追加されました。（http://bugs.adobe.com/blazeds/） 例によって、日本語表示を選択することが可能です。
BlazeDS と Flex （もしくは AIR） アプリケーションの接続にはチャネルの指定が必要です。RPC の利用には LCDS でもおなじみの AMFChannel または HTTPChannel 等を使用しますが、サーバからのプッシュにはこれらに加えて StreamingAMFChannel やStreaminｇHTTPChannel 等が使用できます。
（チャネル名に含まれる AMF と HTTP による違いは送信するデータフォーマットがバイナリ形式かどうかだけなので、この記事では AMF のみ取り扱います）
さて、BlazeDS でのサーバからのプッシュの実現は、3 種類の方法から選択することができます。以下、それぞれの特徴について簡単に説明します。
１．Long Polling （使用するチャネル： AMFChannel）
この方法では、クライアントは通常の HTTP リクエストとしてポーリングをサーバに行います。サーバ側ではクライアントへ送るデータが無かった場合は、そのまま新しく送信するデータが利用可能になるまでレスポンスを保留します。（これがロングポーリングと呼んでいる理由です） クライアントはデータを受信すると次の受信に備えるため、直ちに新しいポーリングのリクエストをサーバに送信します。
クライアントが毎回リクエストを送る手間を除けばほぼリアルタイムのプッシュが実現できます。この方法の利点の一つは、一般的な HTTP のリクエスト・レスポンスのパターンを利用するため、ネットワーク環境について特別に心配する必要がないことです。
下はロングポーリング用チャネルの設定例です。
<channel-definition id="long-polling-amf" class="mx.messaging.channels.AMFChannel"> <properties> <polling-enabled>true</polling-enabled> <polling-interval-millis>0</polling-interval-millis> <wait-interval-millis>-1</wait-interval-millis> <max-waiting-poll-requests>300</max-waiting-poll-requests> ...
まず polling-enabled を true にしてポーリング機能を有効にしています。次の行では polling-interval-millis に 0 を指定することでクライアントがデータを受信したら直ぐ （待ち時間が 0） 次のポーリングを行うよう設定しています。
サーバ側は、wait-interval-millis を -1 にすることで、ポーリングに対するデータが利用可能になるまでずっとレスポンスの送信を保留するようになります。ここまでがロングポーリングの基本設定です。
ロングポーリングで注意が必要なのは、返事を保留しているリクエストの数だけサーバのスレッドがブロックされてしまうという点です。無制限にポーリングリクエストを受け付けたりすると、全てのスレッドが保留状態になってサーバが新規リクエストを一切受け付けられなくなってしまうかもしれません。
そこで、上の例では max-waiting-poll-requests を使い、受け付けられるポーリングリクエストの最大値を 300 に指定しています。実際には、この数値はアプリケーションサーバのスレッドの最大数と、スレッドの使われ方を基準に決定することになることと思われます。
あとは、不要に長時間スレッドを占有する状態を避けるため、wait-interval-millis に例えば 60,000 （1 分） 程度の値を設定して、一旦サーバ側のリソースを開放するという方法も効果があるかもしれません。
なお、同じ HTTP セッションを使って複数のポーリングリクエストを行うことはできません。（サーバ側で制限しています） 例えば、複数の Flash Player インスタンスを同一ブラウザ内で起動する場合、一時点では、どちらか片方のみがロングポーリングを利用できます。
この方法では、サーバがデータをプッシュする度に、クライアントがポーリングリクエストを送るという「余分な」負荷がかかります。沢山のクライアントに頻繁にデータを送るケースではあまり向かない（効率が悪くなる）可能性もあるということですね。
ちょっと長くなったので、続きはまた次回。
Posted by ackie at 06:15 PM | Comments (0)