Curl® 言語で Web アプリケーションを作成したら、ユーザーが実行できるようにこれをサーバーに導入します。通常、アプレットは Web サイトに設置されます。Curl® 実行環境 (RTE) をインストールしたユーザーは、このサイトをブラウズしてアプレットを実行できます。
Curl アプレットを提供するには、3 つの手順を実行して Web サイトを構成する必要があります。
- Web サイトで提供する Curl ファイルの MIME タイプを追加する必要があります。MIME タイプを指定することにより、ブラウザはファイルが Curl RTE で解釈されることを理解します。
- ライセンス キーを導入する必要があります。
- アプレットが、ユーザーの承認なしで Web サイトにあるファイル（例：インポートするパッケージ、インクルードする Curl 言語ソース ファイル、データファイル）にアクセスする必要がある場合は、curl-access.txt 構成ファイルを Web サイトに追加して、これらのリソースへのアクセスを許可する必要があります。
注意: アプレットを提供するホストの管理者以外の方は、ホストの管理者に上記の手順を実行してもらう必要があります。
Web サイトに関して使用されている用語には、定義があいまいなものがあります。Web をブラウズしているときは用語の意味の違いを気にする必要がありませんが、Web サイトを設定して Curl 言語で書かれたアプレットを提供するために、用語の定義を理解しておく必要があります。
- Web サイト は、他のユーザーに公開している HTML ページ、Curl アプレット、画像、データ、およびその他のコンテンツのコレクションです。サイトを訪れると表示されるものです。
- Web サーバー は、Web サイトのコンテンツをブラウザに転送するために使用するソフトウェアです。
- ホスト は、Web サーバーを実行するコンピュータです。
- ホスト名 は、ホストまたは Web サイトを参照するために使用する名前です。ホスト名 www.example.com は、URL (たとえば http://www.example.com/html/demos) の最初の部分です。
- IP アドレス は、ホストを識別する数字を使用するインターネット プロトコル アドレスです。この数字は、通常 192.168.1.1 のように 0 から 255 までの範囲で、4 つのピリオドで区切られた一連の数字で示されます。
| 要約： | - 多くのアプレットは複数のファイルで構成されています。
- Web サイトのコンテンツへの無制限なアクセス許可は、イントラネットの設定において、セキュリティーリスクとなる可能性があります。
- Web サイトで curl-access.txt ファイルを使用して、ファイルへのアプレットの自動アクセスを制限することができます。
|
アプレットは、他の Curl 言語ソース ファイルをインクルードし、パッケージをインポートすることができます。
また、XML データなどのデータ ファイルへのアクセスが必要になることもあります。
Web サイトにこれらのリソースがある場合、アプレットは HTTP プロトコルを使ってアクセスします。
Curl アプレットが無制限に Web サイトにアクセスできるという状況は、セキュリティ上のリスクにつながります。Web サーバーから得られる情報は、たいていの場合は広く世界に公開されています。ただし、内部ネットワーク上にあり、ファイア ウォールで外部から保護されている イントラネット サーバー には、外部に非公開のデータが保存されています。このようなイントラネット サーバーにある極秘データに、ローカル ネットワーク内のクライアント コンピュータにロードされた悪意のある Curl アプレットがアクセスしてそれをローカル ネットワークの外側に送信することも可能であるわけです。
悪意を持つアプレットによる極秘データへのアクセスを回避するために、Curl 言語ではアプレットから Web サイトへの
サイレント
アクセスを規制しています。サイレント アクセスとは、ユーザーへの警告なしで起こるアクセスです。サイレント アクセスでは、アクセスするアプレットを制御するためのディレクティブを含む、
curl-access.txt と呼ばれるファイルが置かれた Web サイトにのみアプレットはアクセスすることができます。
curl-access.txt ファイルがない Web サイトへのサイレント アクセスはできません 例外は、下記の「
curl-access.txt メカニズムの例外」に説明されています。
curl-access.txt ファイルのディレクティブは、アプレットをダウンロードしたサイトを基準にしてアクセスを制御します。
たとえば、関連サイトから来るアプレットだけにアクセスを許可したり、このサイトからダウンロードされたアプレットだけにアクセスを制限することができます。
Curl RTE は次の方法で curl-access.txt ファイルに応答します。
- curl-access.txt のディレクティブがアプレットにアクセスを許可すると、アプレットによるコンテンツ ファイルへのアクセスが成功し、正常に実行されます。
- curl-access.txt ファイルがサイトにあるコンテンツへのアクセスを拒否すると、ファイル アクセスのためにアプレットが呼び出したプロシージャまたはメソッドは SecurityException をスローします。
- curl-access.txt ファイルにディレクティブが含まれていない場合、Curl RTE はアプレットからの直接アクセスをすべてブロックし、ファイル アクセスのために呼び出されたメソッドまたはプロシージャは SecurityException をスローします。
- もし、Curl RTE が curl-access.txt を見つけることができない場合は、ファイルのコンテントへのアクセスは失敗することになります。
image テキスト プロシージャは、Curl によるアクセス システムに関するいくつかの規制から免除されています。つまり、多くのサイトで頻繁にセキュリティ違反を起こさない限り、アプレットは
curl-access.txt ファイルのない Web サイト上で
image を使用して画像にアクセスすることができます。これにより、画像へのアクセスにおいて品行方正なアプレットに柔軟性を与えることになります。
Web サイトに
curl-access.txt ファイルがある場合、
image プロシージャはそれに従います。サイトの
curl-access.txt がアプレット アクセスを許可しない場合、
image プロシージャは画像の取得に失敗します。この失敗はセキュリティ違反としてカウントされます。
アプレットで
choose-file などのプロシージャを使用して、Web サイトのファイルへのアクセスを承認するようユーザーに求めることができます。このファイル アクセスのメソッドではユーザーが明示的にアクセスを承認するので、CURL- アクセス メカニズムによる規制を受けません。詳細については、「
ダイアログ プロシージャ」の章を参照してください。
特権アプレットも CURL- アクセスの規制を受けません。特権アプレットの詳細については、「
セキュリティ」の章を参照してください。
Curl のアクセス メカニズムは主としてイントラネット サイトの保護を目的としているため、一般公開のインターネット Web サイトの場合の構成は非常に簡単になります。
curl-access.txt ファイルに次の内容を含めます。
# curl-access.txt for an Internet Web site
version: 2.0
allow-all:
注意: curl-access.txt ファイルのバージョン番号と Curl API バージョン番号は関連していません。
そのため、バージョン 2.0 の curl-access.txt は 異なる API バージョンと共に使用されます。
このディレクティブ 1 つで、アプレットが配置されている Web サイトに関係なく、すべてのアプレットにアクセスを許可します。このディレクティブはユーザーが HTTP 認証や cookie を使用してログインするような Web サイト上では使用されるべきではありません。そのような場合には、関連のないサイトからのアプレットが現在ユーザーが持っている HTTP 認証や cookie を使用してサイトにアクセスできてしまいます。このような Web サイトでは curl-access.txt ファイルで、より制限の多いディレクティブを使用する必要があります。
このファイルを Web サイトのルートに置いて URL http://your-site-name/curl-access.txt でアクセスできるようにすると、
Curl RTE はこのサイト全体が Curl アプレットからアクセス可能であることを直ちに確認できます。
サイトへのアクセスをアプレットに許可するために必要なその他の手順はありません。
場合によっては、Web サーバーのルートに curl-access.txt ファイルを置けないことがあります。
たとえば、Geocities や Tripod® のような共有コミュニティの Web サイトの場合、このルート ディレクトリへのアクセス権はありません。このような場合、アプレットによるアクセスが必要な各ディレクトリに curl-access.txt ファイルのコピーを置く必要があります。
たとえば、次の URL で ISP のサーバーに個人の Web サイトを設定するとします。
http://www.example.net/users/joesoap/
アプレットはこのサイトのディレクトリ packages からパッケージをインポートし、ディレクトリ data のデータ ファイルにアクセスするとします。この場合、curl-access.txt ファイルの 2 つのコピー (1 つは packages、もう 1 つは data 用) を作成する必要があります。ファイルをコピーしたら、これらのファイルは次のアドレスでアクセスできるようになります。
http://www.example.net/users/joesoap/packages/curl-access.txt
および
http://www.example.net/users/joesoap/data/curl-access.txt
注意: メインのアプレット ファイルがあるディレクトリに curl-access.txt ファイルをコピーする必要はありません。curl のアクセス メカニズムは、アプレットがサーバー上のファイルにアクセスできるかどうかだけを判定するものです。つまり、アプレットのメイン .curl ファイルに Curl RTE がアクセスできるかどうかには関係ありません。アプレットが自立型で、パッケージのインポート、ファイルのインクルード、または画像を除くデータ ファイルへのアクセスを行なわない場合、curl-access.txt ファイルを作成する必要はありません。
allow-all ディレクティブはユーザーがログインしない一般公開の Web サイトでのみ使用する必要があります。イントラネット サーバーまたはユーザーがログインするサーバーでは、このディレクティブを 決して 使用しないでください。使用した場合、Web サーバー上のデータに無許可のアプレットが潜在的にアクセスできることになり、結果として個人情報がイントラネットの外側に流出される可能性があります。イントラネット サイトの curl-access.txt ファイルの作成方法の詳細については、次のセクションを参照してください。
イントラネットは、外部アクセスから保護されている、組織の内部ネットワークです。イントラネットは、ファイアウォールで保護されたプライベート ネットワーク接続で構成することができます。また、無許可のアクセスからデータを保護する目的で一般公開のインターネット上の送信データを暗号化する VPN (仮想プライベート ネットワーク) を使用した接続によってイントラネットを構成することもできます。
curl-access.txt ファイルを使ってイントラネット Web サイトを構成する場合、内部の DNS サーバーでイントラネット内の名前解決を行なう必要があります。プライベート ネットワークの名前解決に公開アクセスの DNS サーバーを使用した場合、DNSなりすましにネットワークを公開することになり、CURL- アクセス メカニズムによって確立された保護が損なわれる可能性があります。
Curl アプレットは、アプレットのホストマシンのアプレットマニフェストなどの補助ファイルにアクセスする必要があります。
アクセスを許可する適切なホストの位置に curl-access.txt を配置して、
アプレットが他の追加リソースのアクセスを要求する際に、そのアプレットがサーバーにアクセスできることを、
Curl RTE が確認できるようにします。 curl-access.txt には、
アプレットをロードする URL に表示されるマシン名の全ての形式およびエイリアスをリストします。
イントラネット Web サイトにアクセス可能なアプレットを制御するために、
curl-access.txt ファイル内で使用できる ディレクティブがいくつかあります。
curl-access.txt ファイルの内容 のセクションを参照してください。
curl-access.txt メカニズムは、Web サイト自体が既に使用しているセキュリティ対策に換わるものではありません。サイトのセキュリティ対策の補助的なメカニズムです。
Web サイト自体が既に使用しているセキュリティ適用後に、curl-access.txt は、どの Curl アプレットがユーザーのサイトにアクセスできるかを判定します。
たとえば、Web サイト www.example.com が example.com、curl.com ドメインのクライアントからのアクセスのみを許可する場合、sample.com ドメインのクライアント ホストが同じ Web サイトからダウンロードしたアプレットは、curl-access.txt ファイルによってアクセスが許可されてもこの Web サイト上のファイルにアクセスすることはできません。
curl-access.txt ファイルを配置する場合、2 つの場所を選択できます。
- Web サイト上のすべてのファイルを同じアクセス ルールの対象にする場合、Web サイトのルートに curl-access.txt ファイルを作成する (たとえば、http://www.example.com/curl-access.txt) 必要があります。
- 一部のディレクトリのみをアクセス ディレクティブの対象にする場合、それらの各ディレクトリに curl-access.txt のコピーを置きます。この場合、curl-access.txt ファイルのディレクティブは、そのディレクトリ内のファイルにのみ関与します。サブディレクトリ内のファイルへは関与しません。
Curl RTE は常に Web サイトのルートを最初に検索するので、ルートにある curl-access.txt ファイルはサーバーのサブディレクトリにある任意のファイルをオーバーライドすることになります。
curl-access.txt ファイルは標準 ASCII テキスト ファイルです。Curl IDE または標準テキスト エディタで作成できます。
version ディレクティブを除いて、
curl-access.txt ファイルは空にすることが可能です。
version ディレクティブのみを含む
curl-access.txt ファイルでは、Web サイトへのアクセスが完全にブロックされます。詳細は、「
Web サイトへのすべてのアクセスの制限」を参照してください。
curl-access.txt の構文は次のとおりです。
| 構文： | version: version-number
directive: [host & domain list]
[directive: [host & domain list]]+ |
|
|
| version-number | ファイル curl-access.txt にあるディレクティブのバージョンです。現在、バージョンは 2.0 です。 |
| directive | Web サイトのファイルにアクセスできるアプレットを定義するのに使用する規則です。詳細は下記を参照してください。 |
| host & domain list | ディレクティブに渡される、ホスト名とドメイン名をコンマで区切ったリストです。各ディレクティブは、渡した名前を個別に処理します。 |
|
curl-access.txt ファイルにはコメントを含めることもできます。コメント行はシャープ記号 (#) で始めます。コメントはコメント行に入力する必要があります。
簡単な curl-access.txt を次に示します。
# A sample curl-access.txt file for a simple Web site.
version: 2.0
home-hostnames: www.example.comcurl-access.txt ファイルには、1 種類のディレクティブのみ含めることができます。ただし、ファイル内に同じディレクティブを複数回含めることができます。これにより、ディレクティブがグループ化され読みやすくなります。有効なディレクティブは次のとおりです。
| ディレクティブ： | allow-all: |
| 説明： | すべてのアプレットに対して Web サイトのコンテンツへのアクセスを許可します。このディレクティブは、一般公開の Web サイトのみに使用することをお勧めします。イントラネット サイトに使用すると、サイトのコンテンツが潜在的に盗用される可能性があります。 |
| 例： |
|
| ディレクティブ： | allow: host-or-domain [, host-or-domain]+ |
| 説明： | 指定するホスト名およびドメイン名にアクセスを許可します。ドメイン名では、ホスト名の最初の部分をワイルド カード文字で指定する必要があります (たとえば *.example.com)。 |
| 例： |
allow: *.example.com, foo.otherexample.com
allow: bar.otherexample.com |
|
|
| ディレクティブ： | allow: host-or-domain [, host-or-domain]+
except: host [, hos
t]+ |
| 説明： | 1 つ以上の allow ディレクティブで指定されたすべてのホストおよびドメインにアクセスを許可し、except ディレクティブで指定された host は拒否します。except ディレクティブは allow ディレクティブとは別の行に入力します。このディレクティブのペアは、内部サイトからダウンロードされたアプレットには Web サイトのデータへのアクセスを許可し、一般公開の Web サイトからダウンロードされたアプレットは除外する場合に役に立ちます。 |
| 例： |
allow: *.development.example.com
except: www.development.example.com
allow: *.sales.example.com
except: demo.sales.example.com, www.sales.example.com |
|
|
| ディレクティブ： | home-hostnames: own-host-name [, alias]+ |
| 説明： | サイト上に設置されたアプレットのみにアクセスを許可します。own-host-name には、Web サイトのホスト名を指定する必要があります。ユーザーが Web サイトの
アクセスに使用する他の別名または省略形は、alias として含めることを推奨します。 |
| 例： |
| home-hostnames: myserver.example.com, myserver |
|
|
注意: curl-access.txt内のディレクティブにてhttps://*.example.com等のホスト名を
http://host や https://hostで定義することにより、
https://スキーマへのアクセスを制御することができます。 そのディレクティブはHostと同様にスキーマからロードされるアプレットと一致します。
設定する規制内容によって、使用するディレクティブが決まります。次のセクションでは、内部 Web サイトの構成に各ディレクティブをどのように使用できるかについて説明します。
クライアント コンピュータのディスクからロードされたアプレット (たとえば、電子メール メッセージからユーザーのコンピュータに保存されたアプレット) は、システムおよびサイトの構成次第で Web サイトにアクセスできます。イントラネット Web サイトの curl-access.txt ファイルを作成する際は、この点を考慮する必要があります。
allow-all ディレクティブを使用するサイトには、常にローカル ファイルからロードされたアプレットからアクセスすることができます。home-hostnames ディレクティブを使用するサイトには、ローカル ファイルからロードされたアプレットからアクセスできません。これは、クライアントマシンからロードされたアプレットのホームホストは Web サイトのホストと異なるためです。
curl-access.txt ファイルで allow あるいは allow ... except ディレクティブを使用するサイトには、クライアント コンピュータがどのようにその名前を通知するかによって、アプレットがアクセスできるがどうかが決まります。Curl 言語がシステム名を取得するために使用するシステム コールで完全ドメイン名 (例：mymachine.example.com) が返された場合、クライアント コンピュータ上のアプレットのアクセスを許可する任意のサイト (つまり、allow: *.example.com のようなディレクティブを使用するサイト) に、このアプレットはアクセスすることができます。システム コールが他の種類の名前を返す場合はホーム ホスト名を持つアプレットになり、したがって allow ディレクティブによって許可されなくなります。
http://localhost URL からロードされたアプレットは、
ローカルコンピューターのホスト名と同一のホスト名を指定する curl-access.txt
ディレクティブを一致させます。
ローカルコンピューターのホスト名に全てのドメイン名が含まれていない場合は、
curl-access.txt ファイル内のディレクティブに短いホスト名を挿入するべきです。
（例： 短いホスト名が mymachine でフルホスト名が mymachine.example.com ）
しかし、ローカルネットワーク外から見える Web サーバーでは、
curl-access.txt ファイルで短いホスト名を使用することが危険な場合もあります。
この短いホスト名は、別の場所にある他の同名のマシンと一致する可能性があるためです。
管理者が、全てのコンピューターをフルホスト名に改名することで
この問題を解決することができます。
改名することができない場合は、http://localhost URL からロードされたアプレットからのアクセスを許可する必要のあるサーバは、
curl-access.txt ファイルにコンピュータの短いホスト名をリストします。
このようなサーバはローカルネットワーク外から見える必要があります。
以下の例は、長短両方のホスト名をリストしています。
# curl-access.txt file
# Only allow own applets access
version: 2.0
home-hostnames: mymachine.example.com, mymachine
次の例は、最も一般的なイントラネット Web サイトの構成で使用する curl-access.txt ファイルを示しています。ほとんどの場合、このサンプルのホスト名とドメイン名を自分のネットワークのものと置き換えるだけで十分です。
これらの例は、ネットワークの特定の Web サイトに対応しています。多くの場合、イントラネットのアプレットすべてのアクセスを許可する Web サイトと、アクセスを限定する Web サイトを構成します。アクセスをできるだけ限定することにより、イントラネットのセキュリティを確保してください。
アプレットは
image テキスト マークアップを使用して、
curl-access.txt ファイルが置かれていないサーバーから画像を取得することができます。この種のアクセスは、
version ディレクティブのみを含む
curl-access.txt ファイルを作成して防ぐことができます。Curl RTE がサイトで
curl-access.txt ファイルを検出すると、画像を含むすべてのファイルへの自動アクセスを拒否します。
version ディレクティブのみを含む
curl-access.txt ファイルが置かれているサイトでは、ユーザー承認によるアクセスのみ許可されます。
version ディレクティブのみを含む curl-access.txt ファイルでは、次の例のように自由にコメントを追加できます。
# This file here to prevent access by Curl applets.
# Do not delete it!
version: 2.0イントラネットの Web サイトに、他の 1 つまたは複数の Web サイトに設置されているアプレットからアクセスできるようにする場合があります。たとえば、支社ごとに Web サイトがあり、そこに設置されているアプレットからデータベースが格納された中央の Web サイトへのアクセスを確立する場合などです。この場合、allow: または allow: ... except: ディレクティブを使用して、中央の Web サーバーで curl-access.txt を作成します。
この構成例では、支社の 1 つでユーザーがローカル Web サイトからアプレットをロードします。ある時点で、アプレットは中央 Web サイトにあるファイルの読み込みを実行します。アクセスを許可する前に、Curl RTE は中央 Web サイトに接続して curl-access.txt ファイルを検索します。支社の Web サイトからダウンロードされたアプレットが必要なデータにアクセスするために、中央 Web サイトのファイルはこのアプレットのアクセスを許可する必要があります。
たとえば、Example Co. という会社に支社の Web サイトが 4 つあると想定します。
- north.example.com
- south.example.com
- east.example.com
- west.example.com
さらに、1 つの Web サイト (central.example.com) にはデータベースが接続されていて、支社のサイトに設置されたアプレットはこれにアクセスする必要があります。
この場合、central.example.com 上でさまざまな curl-access.txt ファイルを使用して、アプレットが必要とするアクセスを許可します。
最も簡単で、したがって安全ではない curl-access.txt ファイルの例を次に示します。
# central.example.com curl-access.txt file
# Allow the entire example.com domain
version: 2.0
allow: *.example.comこの構成ファイルは、example.com ネットワーク上で支社のサーバーだけが Curl アプレットを設置している Web サイトである場合に使用してください。後で他のサーバーに Curl アプレットが導入されると、これらのアプレットも central.example.com のコンテンツにアクセスできることになります。
example.com ネットワークで安全性の高い curl-access.txt ファイルを次に示します。
# central.example.com curl-access.txt file
# Allow just the regional servers
version: 2.0
allow: north.example.com
allow: south.example.com
allow: east.example.com, west.example.comこの構成では、example.com のネットワーク上で別の Web サイトが Curl アプレットを導入しても、それらは central.example.com コンテンツに自動的にアクセスできません。
central.example.com の Web サイトへのアクセスを制限するもう 1 つのアプローチとして、特定のサイトを除いて、その他のイントラネット サイトが提供するすべてのアプレットにアクセスを許可する方法があります。たとえば、example.com が多数の支社の Web サイトから central.example.com へのアクセスを許可する一方で、一般公開されている www.example.com などのサイトからはこれを不適切として除外するように決定したとします。この例のような除外に基づく制限は、allow: ... except: ディレクティブを使用して実行できます。
# central.example.com curl-access.txt file
# Allow all servers except publicly accessible ones
version: 2.0
allow: *.example.com
except: www.example.comイントラネット Web サイトの 1 つにアプレットを設置し、同じサイトのコンテンツには他のサイトのアプレットからのアクセスを許可しないように構成する必要があります。このような場合、サイト上のアプレットだけにアクセスを制限します。この制限は home-hostnames ディレクティブを使用して作成します。
home-hostnames ディレクティブは、Web サイトの別名であるホスト名のリストを受け入れます。Curl RTE が home-hostnames ディレクティブを含む curl-access.txt ファイルを検出した場合、そのサイトがアプレットのホーム ホスト (アプレットのダウンロード元の Web サイト) であれば、Web サイト (ターゲット ホスト) へのアクセスを許可します。
Curl RTE は、ディレクティブにある名前をアプレットのホーム ホスト名と比べて、アプレットが接続しようとしている Web サイトがアプレットのホーム ホストであるかどうかを判断します。
ホスト名のマッチングに加えて、Curl RTE はホームとターゲット ホストの両方の IP アドレスを比較して、アプレットが接続しようとしているホストが実際にホーム Web サイトであるかどうかを確定します。
さらに、ホーム名とターゲット Web サイトのホスト名の DNS ルックアップを実行してその結果を比較します。ターゲット ホストの IP アドレスがホーム ホスト名の IP アドレスに一致した場合、ターゲット ホストへのアクセスを許可します。
home-hostnames は、IP アドレスが home-hostnames ディレクティブのリストにない場合も、ホストの IP アドレスを含む URL からロードされたアプレットにもアクセスを許可することに注意してください。
Web サイト上にコンテンツを提供する複数のホストがある場合、DNS ルックアップにより複数の IP アドレスが返されます。ターゲットとホーム ホストの DNS ルックアップで複数の IP アドレスが返される場合は、ターゲット ホストの IP アドレス リストがホーム ホストの IP アドレス リストのサブセットである必要があります。
たとえば、example.com のイントラネット上の Web サーバー (private.example.com) が、サーバー自体のアプレットのみがアクセスできるコンテンツを提供するとします。この Web サーバーには home-hostnames ディレクティブを使用する curl-access.txt ファイルを置いて、サーバー上のアプレットのみアクセスが許可されるようにします。
# private.example.com curl-access.txt file
# Only allow own applets access
version: 2.0
home-hostnames: private.example.com, private上記のファイルでは、サーバーの完全ホスト名を home-hostnames ディレクティブに含めます。ユーザーはドメイン名を使わずにローカル Web サイトにアクセスできることから、別名の private も含まれています。home-hostnames ディレクティブには、ユーザーがアプレットのロードに使用する別名および省略形も含める必要があります。
curl-access.txt ファイルは、アプレットのソケット接続にも関連しています。ただし、ソケット接続を開くアプレットに許可されるアクセスは非常に限られています。
- Curl RTE は、アプレットのホーム ホストへのソケット接続のみ許可します。アプレットを提供したサイト以外のサイトに対してソケット接続を開こうとすると、Curl RTE は接続をブロックします。
- Curl RTE は、常にホストの既定の Web サイトに接続して curl-access.txt ファイルを探します。既定の Web サイトは、ブラウザでホストの IP アドレスを入力すると到達するサイトです。
- Curl RTE は、Web サーバーのルート ディレクトリ内しか調べません。これにより、curl-access.txt ファイルがサイト管理者によって設定されたことを確認します。アプレットがホストのポートにアクセスできるかどうかは、ホストの管理者のみが決定すべきです。
- ソケット接続の場合、アプレットはホーム ホストのみアクセスが許可されるので、ソケット アクセスで有効な唯一のディレクティブは home-hostnames になります。Curl RTE が curl-access.txt ファイル内で他のディレクティブを検出した場合、ホストへのアプレット アクセスは拒否されます。
Curl RTE は crossdomain.xml と名付けられたポリシー ファイルを使用したクロスドメイン サンドボックス セキュリティー システムをサポートしています。これは Adobe Flash やそれに関連するテクノロジーにも使用されています。
非特権アプレットが Web サイトにアクセスしようとするとき、curl-access.txt ファイルが見つからない場合は、Curl RTE はアプレットがアクセスしようとしている Web サーバーのルート ディレクトリ内の crossdomain.xml と呼ばれるファイルをチェックします。
crossdomain.xml ファイルは0個またはそれ以上の allow-access-from 要素と共に cross-domain-policy のルート要素を基本フォーマットとして持つ XML ファイルです。allow-access-from 要素はこのサーバーにどのアプレットがアクセス可能かを示す domain 属性を持っています。allow-access-from 要素はまた、secure 属性も持つことができます。secure 属性が true の場合、https: URL 経由でサーバー上のコンテンツにアクセスを許可されるように アプレットが https: URL 経由でロードされたということです。secure の既定値は true です。
例：
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="master-only"/>
<!-- allows accesses from applets hosted on www.example.com -->
<allow-access-from domain="www.example.com" />
<!-- allows accesses from applets hosted on example.net or *.example.net -->
<allow-access-from domain="*.example.net" />
</cross-domain-policy>
すべてのアプレットからのアクセスを許可するファイルの例：
<?xml version="1.0"?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*" secure="false"/>
</cross-domain-policy>
| 要約： | - MIME (Multipurpose Internet Mail Extensions) タイプを指定して、ブラウザに Curl RTE を使用して Curl ファイルを表示するよう指示します。
- MIME タイプの追加方法については、Web サーバーのマニュアルを参照する必要があります。
|
Web サイトから Curl アプレットを提供するには、
Curl ソース ファイルの MIME タイプ定義を Web サーバー構成に追加する必要があります。
MIME タイプを使用して、サーバーはコンテンツが Curl RTE で処理されるようブラウザに通知します。
Microsoft® Internet Information Services (IIS)を
使い、アプレットを提供する場合、下記にあげる全てのMIMEタイプを定義する必要があります。
-
.dat 拡張子は、Curl のライセンスファイルであることを示します。.dat ファイルは MIME タイプ application/octet-streamを使用して提供します。その他の MIME タイプは .dat に使用できますが、IIS では、いくつかのタイプを指定するよう要求します。
-
.curl 拡張子は、ブラウザ内で実行する Curl アプレットファイルであることを示します。
.curl ファイルは、MIME タイプ text/vnd.curl を使用して提供します。
-
.dcurl 拡張子は、独立型アプリケーションとして実行することのできる独立型アプレットファイルであることを示します。
.dcurl ファイルは、MIME タイプ text/vnd.curl.dcurl を使用して提供します。
-
.scurl 拡張子は、パッケージとパッケージに含まれるコードを定義する Curl ソースコードであることを示します。
.scurl ファイルは、MIME タイプ text/vnd.curl.scurl を使用して提供します。
-
.mcurl 拡張子は、アプリケーションリソースを体系化する Curl マニフェストファイルであることを示します。
.mcurl ファイルは、MIME タイプ text/vnd.curl.mcurl を使用して提供します。
-
.pcurl 拡張子は、プリコンパイルされた Curl パッケージであることを示します。
.pcurl ファイルは、MIME タイプ application/vnd.curl.pcurl を使用して提供します。
-
.car 拡張子は、 随時接続コンピューティング (OCC) で使用される Curl アーカイブ ファイルであることを示します。
.car ファイルは、MIME タイプ application/vnd.curl.car を使用して提供します。
注意: Microsoft® Internet Explorer は、Web サーバーが適切な MIME タイプで構成されていない場合でも Curl アプレットを表示することができます。このブラウザは、ダウンロードされるファイルの .curl 拡張子によって Curl RTE がファイルを処理することを判定します。
ダウンロードされたコンテンツがプラグインで処理されるかどうかの判定に拡張子を使用しない他のブラウザもあります。このようなブラウザは、代わりに、Web サーバーが適切な MIME タイプで構成されていない場合にファイルのソース コードを表示します。
MIME タイプの追加方法はご使用の Web サーバーによって異なります。たとえば、Windows NT または 2000 で実行している Apache Web サーバーの場合、次のファイルを編集して、
Path to Apache's Install Directory\conf\mime.types
次の行を追加する必要があります。
独立型アプレットを使用している場合は次の行を追加します。
text/vnd.curl.dcurl dcurl
他の Curl ファイルタイプに関しては必要に応じて追加行を挿入します。
メインのサーバー構成ファイルへのアクセス権がない場合 (Web サーバーの管理を委託している場合など) は、.htaccess ファイルを使用することにより、専用ディレクトリのファイルの MIME タイプ をコントロールできます。Curl アプレット ファイルが収められているディレクトリに次の行を含む .htaccess ファイルをコピーします。
AddType text/vnd.curl .curl
AddType text/vnd.curl.dcurl .dcurl
AddType text/vnd.curl.scurl .scurl
AddType text/vnd.curl.mcurl .mcurl
AddType application/vnd.curl.pcurl .pcurl
AddType application/vnd.curl.car .car
.htaccess ファイルの構成は、アプレット ディレクトリとすべてのサブディレクトリに適用されます。
.htaccess ファイルの使用の詳細については、
apache.org (英語) から情報を入手できます。
MIME タイプの追加方法を確認するには、ご使用の Web サーバーのマニュアルを参照してください。
Microsoft Internet Information Server (IIS) の構成オプションには、Curl ファイルの提供に関して問題を起こす可能性があるものがあります。IIS には、コンテンツがキャッシュに保存されないように、提供するすべてのコンテンツを直ちに期限切れにするよう強制する構成オプションがあります。IIS がこのように構成された場合、IE (Internet Explorer) による Curl アプレットのダウンロードおよび実行に関して問題が発生します。IE はアプレットを表示する代わりに、ファイルのダウンロード ダイアログ ボックスを開きます。ユーザーがこのダイアログ ボックスで行なう操作はすべて無視され、IE は ファイルが見つかりません
というエラーを表示します。
この問題を回避するには、IIS で即座に期限切れにならないように設定します。期限切れを数秒後に設定するだけでこの問題は解決します。
Curl 言語 Web アプリケーションが Web サイトに設置されている場合、Web サーバーを構成して、ファイルを提供する際に送信する HTTP ヘッダーに Content-Type charset パラメータを追加することができます。このパラメータにより、クライアントは送信された HTTP 文書のエンコーディングを判別します。ファイル内に curl-file-attributes 式による別のエンコーディングの指定が無い限り、Curl RTE は Content-Type パラメータを調べてファイルの文字エンコーディングを判別します。
| 要約： | - Curl アプリケーションの HTTP サーバはライセンスキーを供給する必要があります。
- SCSK 株式会社からライセンスキーを取得します。
- ライセンスキーは Web ルートか、アプリケーションがあるディレクトリに配置される必要があります。
|
ライセンス キー とは、HTTP サーバーにインストールする目的で SCSK 株式会社が提供する署名済みバイナリ ファイルです。
HTTP サーバー上のライセンス キーによって、そのサーバーからアプリケーションを実行することを Curl RTE に許可します。
ウェブサイトから提供されるアプレットをhttp://localhost/...を利用してシュミレーションすることができます。
Curlアプレットにとっては、file: スキームよりもローカルホストのほうがよりよいテスト環境を提供できます。
file:スキーマはライセンスキーが不要で、Curl Proの機能を利用することができます。
無償のCurlライセンスを使ったアプレットがfile: URLから実行される場合、異なる動きをすることがあります。
ローカルHTTP Deploymentを可能にする特別なライセンスキーを発行することも可能です。
それらのキーはCurl インストールに含まれ、d:\automated-build-temp\build\win32-atom\ide\etc\localhost\curl-license-5.dat及びd:\automated-build-temp\build\win32-atom\ide\etc\localhost-pro\curl-license-5.datに格納されます。
ライセンス キーには、配置されるアプレットに対応する 1 つ以上の有効な URL と関連している必要があります。
SCSK 株式会社にライセンス キーを要求する際にはこの URL を指定してください。
URL はサーバーの IP アドレスではなく、配置するアプレットの場所を表すものです。
マシン上のすべての Curl アプレットのライセンスを得るには、トップレベルのマシン名を指定します。
たとえば、URL が http://www.example.com/ の場合、
http://www.example.com/ にあるすべてのアプレットにライセンスを与えることになります。
特定のディレクトリにある Curl アプレットのライセンスを得るには、そのディレクトリの URL を指定します。
たとえば、http://www.example.com/level1/ の場合、
ディレクトリ http://www.example.com/level1/ とサブディレクトリにあるすべてのアプレットにライセンスを与えることになります。
ローカル ディプロイメントの実行中は、ファイル URL を使ってリソースにアクセスするためにライセンス キーは必要ありません。
Curl アプレットを HTTP ホスト上に配置し、個々の Curl 実行環境クライアントがアクセスできるようにする場合にライセンスキーが必要になります。
アプリケーション ディプロイメントに関するライセンス キーの取得方法の詳細は、Curl 社の Web サイトから入手できます。
ライセンス キー ファイルの名前は変更できません。
ファイルの名前を変更すると、Curl RTE がこれを検索できなくなります。
URLプレフィックスは、ワイルドカードのない任意のホスト名ですが、冒頭のワイルドカードに続けて DNS 名として知られている構成要素を使う必要があります。
以下の例ではライセンスを使用する際の正当な URL プレフィックスを示します。
http://example/products/
http://*.example.com/products/
以下の例はライセンスを使用する際の正当な URL プレフィックスではありません。
http://*.example/
http://*/products/ ライセンス キーは、Web ルート ディレクトリまたは Curl 言語のアプリケーションが保存されているディレクトリに置くことができます。
Curl RTE は最初に Web サイトのルートを調べ、ライセンス キーを見つけるとそれ以上は探しません。
したがって、ルートにあるライセンス キーはサーバーの他の場所にあるキーより優先されることになります。
すべてのディプロイメント ディレクトリに対して 1 つのライセンス キーを使用する場合、Web ルートに置くのが最も効果的です。
サーバーの Web ルート ディレクトリにライセンス キーが見つからない場合、Curl RTE はダウンロードするアプリケーションのディレクトリでキーを探します。
たとえば、ホスト名 http://www.my-server.net のサイトの http://www.my-server.net/contents/demos/some-Curl-app/start.curl にアプリケーションがあるとします。
- Web ルートのライセンス キーは http://www.my-server.net/curl-license-5.dat、
- アプレット専用のライセンス キーは
http://www.my-server.net/contents/demos/some-Curl-app/curl-license-5.dat です。
- いずれの場所にもライセンス キーが見つからない場合、Curl RTE はエラー メッセージを返します。
サーバーの Web ルートへのアクセス権がない場合 (ISP 提供のサーバーを使用する場合など)、
または異なる組織がそれぞれ別の期間中に Curl コンテンツをサーバー上に発行する場合、
アプリケーションごとにライセンス キーを配置しておくと、1 つのキーを調整する手間が省けます。
注意: Curl RTE はライセンス ファイルの読み取り時に HTTP 失敗をキャッシュします。
したがって、ライセンス ファイルを追加または削除したらその後で Curl RTE を終了して再起動してください。
この手順を実行しない場合、Curl RTE は現在置かれているファイルではなく、キャッシュした値を基準にしてしまいます。
その結果、ライセンス ファイルが適切に配置されていてもアプレットが失敗する可能性が生じます。
Curl では、Curl アプレットにアクセスできるユーザー数に制限がある、制限つき RTE ライセンスを提供しています。制限つきライセンスを使用するにはクライアントコンピュータごとに RTE クライアント ライセンスが必要となります。Curl では、制限つきライセンスには SafeNet Sentinel LM™ ライセンスソフトウェアが必要となります。ライセンスの購入およびネットワーク ライセンス サーバーのセットアップについては、
Curl の Web サイト を参照してください。
制限つき RTE ライセンスには、各マシンに生成されるスタンドアロン ライセンスとマシンの数を指定するネットワーク ライセンスがあります。制限つきアプレットをディプロイする場合は、ユーザーは [Curl コントロール パネル] 上の [ライセンス] タブを使用して、ユーザーのマシンに RTE のライセンスを与える必要があります。
ネットワーク ライセンスを使用する場合、エンドユーザーはネットワーク ライセンス サーバー の URL を入力するか、リストから選びます。スタンドアロン ライセンスを使用する場合は、エンドユーザーはSCSK 株式会社にユーザーとサーバーを識別する情報とともにそのマシンを識別するコードを送り、ライセンス コードを取得しなければなりません。フィールド上の [ライセンス] タブはそのマシンを識別するコードを表示します。[スタンドアロン ライセンスのリクエスト] ボタンは Curl の web サイト上のページを開き、そこでライセンス キーをリクエストすることができます。
ネットワーク ライセンスを使用する場合、[ライセンス] タブ上の追加のフィールドでどのマシンをネットワーク ライセンス サーバーにするかを選ぶことができます。
RTE のライセンスを取得すると、[ライセンス] タブに [ライセンス解除]ボタンが現れ、ネットワーク ライセンスのユーザーはこのボタンを使用して、他のユーザーが使用できるようにライセンスを解除することができます。ライセンスが解除される前に、RTE を終了しなければなりません。
ユーザーがライセンスを受けていない RTE を使用中にライセンスを必要とするアプレットをブラウズすると、アプレットで捕捉されなかった例外エラーとなります。エラーのテキストは状況を説明します。アプレットの制作者はこの例外を処理し、必要に応じて追加情報をユーザーに提供することができます。
Copyright © 1998-2019 SCSK Corporation.
All rights reserved.
Curl, the Curl logo, Surge, and the Surge logo are trademarks of SCSK Corporation.
that are registered in the United States. Surge
Lab, the Surge Lab logo, and the Surge Lab Visual Layout Editor (VLE)
logo are trademarks of SCSK Corporation.
