Web サイトがうまく設計されていれば、そのページの利用者は容易にサイトを見て回り、不満やいらいらを感じずに必要な情報を見つけだすことができます。これは利用者を導く多くのリンクやサイトマップによって達成されます。サイトを管理する上で大きな問題は、リンクやサイトマップを最新の状態に保つことです。利用者が最もがっかりするのは、開こうとしたリンクが切れていたときなのです。
Web サイトの構成はとても複雑かつ変化しやすいものですので、内部のリソースを再構成しても URL やリンクを有効なままに維持する方法があることは有用です。サイト管理だけに限らず、このことは Web サイト内の興味をもったページにブックマークしている顧客にとっても利益となります。
Iris Today の記事、ドミノ Rnext で Web アプリケーションを作る：Webサイト・アドレッシングに関するチュートリアルには、ドミノ Rnext で Web サイトをセットアップするための基礎について説明してあります。本記事では、Web サイトの構成を管理するときに助けとなる Web site rule（Web サイト・ルール）の使い方についてみていきます。Web site rule が incoming URL（サーバーが受け取った URL）の解釈を制御する方法を提供することにより、サイト管理が容易になります。ルールには2つの主な使い方があります。
この記事は、ドミノ Rnext を使って Web サイトを立ち上げようと考えている全てのシステム管理者と Web マスターにとって興味深いものとなります。ここでは、ドミノ・ディレクトリーおよびシステム管理の仕事になれていることを前提とします。
Web Site Rule（Web サイト・ルール）文書
Web site rule はドミノ・ディレクトリーにおいて、[Server] - [Internet Sites] ビューのなかで Web サイト文書に対して返答文書を作ることにより定義されます。Web サイトに対して定義された他の情報全てと同じく、ルールはその親サイトに対してのみ適用されます。しかし、ルールは単純な返答文書として実装されているので、同じルールを複数のサイトに適用したいならば、単純にそのルールを別のサイトへコピー＆ペーストすればよいのです。
このサイトに対してルールを作成するために、[Web Site（Web サイト）] アクション・ボタンをクリックし、[Create Rule（ルールの作成）] を選択してください。すると、新しい Web Site Rule 文書が現れます。
このフォームの [Type of rule（ルールの種類）] フィールドでは、[Directory（ディレクトリー）]、[Redirection（リダイレクト）]、[Substitution（置換）] の3種類から選択できます。この記事では、[Redirection]、[Substitution] のルールについて説明します。[Directory] については今後掲載される記事をご覧下さい。その記事では Web サイトのファイル・システム・リソースをセットアップする方法について説明する予定です。
[Type of rule] フィールドで [Substitution] を選ぶと、フォームには Substitution ルールのためのフィールドが表示されます。
Type of ruleを Substitution でなく Redirectionに設定した場合は、[Replacement pattern] フィールドの代わりに [Redirect to this URL（リダイレクト先の URL）] というフィールドが表示されます。これもワイルドカードを利用できるテンプレートです。
Incoming pattern と Replacement pattern の使い方を理解する前に、まず、Rnext Web サーバーがどのようにブラウザー・クライアントから送られた URL を処理しているかを知る必要があります。
Web 管理者ならよくご存じのように、インターネットは、いたずら程度のものからサイバー・テロのレベルまで絶えず悪意のある人間による攻撃にさらされています。一部のインターネット・ソフトに脆弱性が発見されると、その脆弱性を狙った攻撃ソフトがすぐに作成され、ばらまかれます。特定の標的に対しての場合もありますが、多くはインターネット全体に対する攻撃です。パブリックな Web サーバーが、他の標的をねらった攻撃によって被害を受けるということもよくあります。特定のソフトをねらった攻撃が他のベンダーのソフトに深刻な影響を及ぼすこともあります。
ルールは Web マスターのための管理機能です。ルールはセキュリティー機能ではありません！ルールを Web サイトの一部を隠すために使うと、「セキュリティーを混乱させる」という罪を犯したことになります。これはまったくセキュリティーのない状態であるということが、何度も繰り返し証明されています。実際、これは見せかけのセキュリティーを提供するので、セキュリティーのない状態よりも悪いかも知れないのです。あなたが他の事柄に不注意になってしまう可能性が非常に高いのです。
間違っています！セキュリティー上の大間違いを犯しています。まず、あなたはデータベースがレプリカ ID によって Web からアクセスできることを忘れています。例えば、internal\names.nsf は http://www.myco.com/85256ab40043144e?OpenDatabase によってアクセスされるかも知れません。レプリカ ID は 16 進数の文字列ですが、それが本当にランダムになっていないこと、および今日の安価なコンピューター・パワーと帯域の広い通信網があることから、多くの要求によってサーバーを攻撃し有効なレプリカ ID を見つけることは攻撃者にとって何でもないことです。第2に、データベースを移動したりデータベースの名前を変更したりすることにより、セキュリティーを自ら弱めてしまうかも知れません。internal\specs.nsf から planning\specs.nsf へ移動したときに、internal.myco.com に対するリンクとルールを修正することは忘れないでしょうが、www.myco.com に対するリダイレクト・ルールを修正することは忘れてしまう可能性があります。すると、http://www.myco.com/planning/specs.nsf を要求しても、そのデータベースを開くことはできなくなります。
例2：ドミノによらないサイトをドミノへ変換する
単純なショッピングモール Web サイトを考えてください。そのサイトのコンテンツは、ショッピング・モールの各店舗に対応するディレクトリーに保存された HTML ファイルだとします。この基本的な方法によるサイトをドミノへアップデートし、HTML ファイルをドミノ・ページにコピーして、各店舗に対するドミノデータベースを作ったとします。前の例と同じく、これによりページ内のスタティック・リンクは切れてしまいます。しかし、データベースの名前をもとのディレクトリー名と同じにしてあって、ページの名前をもとのファイルの名前と同じにしてあれば、サイト全体に適用できる次のような Substitution rule をひとつ作れば済みます。
ワイルドカードは Internal redirection において必須ではありませんが、[Incoming URL pattern] と [Redirect to this URL] フィールドの両方で使うことができます。しかし、Substitution を使えば済むので、それを行う意味はあまりありません。また、Internal redirection を GET あるいは HEAD 以外の要求に対して用いることはできません。
