Ver.1.16 2001/01/11

LQアクセス制限ライブラリのヘルプ

「”サル”というのは若者のためにある言葉だ。」　−飯島愛

アクセス制限の概要

　このライブラリでは、特定の相手からのアクセスを禁止するために複数のアクセス制限の方法を用意しています。 これは、特定の相手からのアクセスだけを禁止する確実な方法が現実には存在しないからです。
　つまり、ここで用意しているアクセス制限は、いずれも、完全に特定の相手を締め出すことができなかったり、他の無関係の人も巻き添えにして締め出すことになるという欠点があります。
　このため、実際にアクセス制限を実行するには、個々のケースに応じて最適なアクセス制限方法を選択しなければなりません。 また、いずれが最適なアクセス制限方法であるかは、このライブラリを組み込んだCGIの設置サイトの環境やアクセスを禁止したい相手のアクセス環境、インターネットに対する知識量などに応じて変わって来ます。

　基本的な選択方法としては、
  1. アクセスを禁止したい相手がクッキーを受け付けていてユーザーIDが設定されているなら、「禁止ユーザーID」を登録する。
    クッキーを受け付けない無関係な人を排除しても問題ないのなら、「ユーザーIDによるPOST制限」を設定する （必要に応じて、「ユーザーIDの新規発行の停止」も設定する）。

  2. アクセスを禁止したい相手がプロバイダからアクセスしているなら、「禁止ホスト名」を登録する。
    この場合、無関係の人がアクセスを禁止されるのを回避するには「許可ユーザーID」を登録する。

  3. アクセスを禁止したい相手が公開プロキシサーバー経由でアクセスしているなら、「プロキシサーバー制限」と「ドメインの国制限」を設定し、それでも禁止できないプロキシサーバーには「禁止IPアドレス」を登録する。
    この場合、無関係の人がアクセスを禁止されるのを回避するには「許可IPアドレス」や「許可ユーザーID」を登録する。

　以下に、このライブラリが提供するアクセス制限の概要を説明します。


　Web上で操作を行うことにより、上記のアクセス制限の登録／削除や設定／解除を簡単に行うことができます。

　タチの悪い荒らしの常習者は、問答無用です。 下手に相手をしてカリカリする前に、このライブラリを利用して、手軽に、そして場合によっては根気良くアクセス制限を行うことにより、鬱陶しい荒らしをトットと排除して下さい。

　ただし、このライブラリは、些細なネット上のモメゴト程度のことで、気に食わない相手を締め出すために使うものではありません。
　「その他のアクセス制限」で示したものを除く他の全てのアクセス制限は、「アクセス制限の実行」を設定しない限り実際にはアクセスを禁止しないので、例えば事前にアクセス制限の登録だけを行っておき、タイミングを見計らって、いっせいに実際のアクセス禁止を行うようにすることができます。
　常習的な荒らしに狙われた場合は別にして、一般の掲示板などでのモメゴトは、管理人に余裕がないために、通常の訪問者が売り言葉に買い言葉で荒らしに豹変するケースも少なくないようです。 このような場合に、例えば禁止ホスト名の登録などを行って、いつでも相手をアクセスを禁止にできる状態にしておくことができるので、その間に頭を冷やして冷静になり、不用意にアクセス禁止の措置を採らなくても済むように、管理人に余裕を持って頂くことも、このライブラリを作成した目的の一つです。

アクセスログの見方

　まずは、最初にアクセス制限の概要を参照して下さい。

　アクセスログページの最初の部分には、最も最近に設定したユーザーIDの後半に付加したカウント値を表示します。 この数字は基本的にはアクセスのカウント値ですが、ユーザーIDの設定を行っている場合には、ユーザーIDが設定された人のアクセスを重複してカウントしないので、理想的には訪問者数を表すことになります（ただし、クッキーを受け付けない相手は重複してカウントします）。
　また、アクセス制限の実行で実際にアクセス制限が行われるように設定されている場合には、この右側に下の例のように赤字で「アクセス制限実行中」の表示が行われます（プロキシサーバー制限とドメインの国制限とユーザーIDによるPOST制限が設定されている場合は、これらの表示も行われます）。
LAST ID1293アクセス制限実行中

　アクセスログの本体では、下のようなテーブルで１件のアクセスを表します。
　以下、このアクセス例に基づいて下に詳細な説明を行います。
001: 2000年12月10日(日) 19時38分36秒 (GET METHOD)
処理結果IPアドレスホスト名ID
アクセス制限しない211.13.26.126IP1A0634.osk.mesh.ad.jpUnyk374
現在設定での検査結果現在登録での検査詳細
アクセス制限しない（該当登録なし）
環境変数環境変数の値
HTTP_COOKIEPETIT=name:プチ,email:,url:,pwd:,color:800000; CRU=Unyk374
HTTP_USER_AGENTMozilla/4.0 (compatible; MSIE 5.0; Windows 98)
[HELP]
 ホスト名 の
[HELP]
 IPアドレス [211.13.26.126] の
[HELP]
 アクセス禁止の有効期限　 30日 90日 180日 360日
[HELP]
 ユーザーID [Unyk374] の
[HELP]
 ユーザーID [Unyk374] の
[HELP]
 IPアドレス [211.13.26.126] の

　最初の行は、アクセス日時を表示します。 　日時の前の「001:」は、アクセスログ上での最新のものからの通し番号です。 　日時の後の「(GET METHOD)」は、アクセスがGET METHODであることを表します。
001: 2000年12月10日(日) 19時38分36秒 (GET METHOD)

　POST METHODによるアクセスの場合には、以下のように背景色がオレンジ色に変わります。
　このアクセスが投稿の場合には、この日時をCGIの投稿日時と照らし合わせて、誰のアクセスであるかを確認します。
001: 2000年12月10日(日) 19時38分36秒 (POST METHOD)

　２〜３行目の左端の「処理結果」の欄は、このアクセスが実際にアクセスを禁止されたかどうかの結果を表示します。
　アクセスが禁止される場合は、赤字で「アクセス禁止」と表示されます。 また、繰り返しのPOSTアクセスの制限の設定によりアクセスが禁止された場合には、赤字で「重複POST禁止」の表示になります。
　なお、LQアクセス制限ライブラリがアクセスを許可しても、組み込んだCGI自身が重複投稿禁止などの機能によってアクセスを禁止する場合があるので注意して下さい。
　その右側の「IPアドレス」の欄は、アクセス元のIPアドレスを表示し、次の「ホスト名」の欄は、そのIPアドレスに設定されたホスト名を表示します（IPアドレスとホスト名参照）。 そのIPアドレスにホスト名が設定されていない場合には、「ホスト名」の欄が「?」となります。 全てのアクセスで、この「ホスト名｣の欄が空欄になっていたり、IPアドレスがそのまま表示されている場合には、ホスト名の取得の設定を確認して下さい。
　右端の「ID」の欄は、アクセス相手のブラウザなどに設定されたユーザーIDを表示します。 ユーザーIDが設定されていない場合には「-」の表示となります。
処理結果IPアドレスホスト名ID
アクセス制限しない211.13.26.126IP1A0634.osk.mesh.ad.jpUnyk374

　４〜５行目の左端の「現在設定での検査結果」の欄は、現在の設定や登録で、これと同じ条件のアクセスがあった場合に、アクセスが禁止されるかどうかの検査結果を表示します。 アクセス制限の設定や登録を変更した場合には、これが有効かどうかの確認を行うことができます。
　アクセスが禁止される場合は、赤字で「アクセス禁止」と表示されます。 また、アクセス制限の実行で、POST METHODだけを制限している場合には、「アクセス禁止(POST)」と表示されます。 　ただし、アクセス制限の実行で「制限しない」の設定になっている場合には、常に「アクセス制限しない」という表示になり、設定に応じてアクセスが禁止される場合に、その下に、「（アクセス制限実行時禁止）」の表示が現れます。
　右側の「現在登録での検査詳細」の欄は、現在のアクセス制限の登録で該当するものの一覧を表示します。
現在設定での検査結果現在登録での検査詳細
アクセス制限しない（該当登録なし）

　この欄は、アクセス制限の実行の設定とは無関係に、登録された該当するアクセス制限が全て表示されます。 従って、そのアクセスがどのようなアクセス制限の登録に該当するかを確認することができます。
　下のように「禁止ホスト名」などのアクセス制限が表示された場合には、アクセス制限の実行の設定を変更することにより、以降の同じ条件のアクセスを実際に禁止することができます。 これは、左欄の「（アクセス制限実行時禁止）」の表示でも確認できます。
現在設定での検査結果現在登録での検査詳細
アクセス制限しない
（アクセス制限実行時禁止）		禁止ホスト名 (IP .osk.mesh.ad.jp)

　ただし、下のように、一覧の一番最初に「許可ユーザーID」か「許可IPアドレス」が表示されている場合には、その後に他のアクセス制限が表示されている場合であっても、アクセスは禁止されません。
現在設定での検査結果現在登録での検査詳細
アクセス制限しない許可ユーザーID (Unyk374)
禁止ホスト名 (IP .osk.mesh.ad.jp)

　なお、この一覧で同様のアクセス制限が複数表示されている場合には、重複登録の可能性があるので、既登録編集ページで無駄な登録を削除して下さい。
　もっとも、下のように、「禁止ユーザーID」と「禁止ホスト名」などのように種類の異なるアクセス制限は、重複して登録することが無意味であるとは限りません。
現在設定での検査結果現在登録での検査詳細
アクセス制限しない
（アクセス制限実行時禁止）		禁止ユーザーID (Unyk374)
禁止ホスト名 (IP .osk.mesh.ad.jp)

　また、下のように、この欄に「プロキシサーバー」と表示された場合には、プロキシサーバー制限の設定を行うことによりアクセスを禁止することができます。
　しかし、これがアクセスを禁止しては困る相手であった場合には、事前にこのプロキシサーバーのIPアドレスを「許可IPアドレス」として登録しておくこともできます。
　なお、この表示が「プロキシサーバー（接続元あり）」となった場合には、プロキシサーバー制限で「匿名プロキシサーバーのみを制限する」の設定を行うことにより、アクセスを禁止しないようにすることができます。
　なお、ここで「プロキシサーバー」と表示されても、プロキシサーバー制限の設定が行われていない場合には、左欄で「（アクセス制限実行時禁止）」の表示は行われません。
現在設定での検査結果現在登録での検査詳細
アクセス制限しないプロキシサーバー

　この欄では、「プロキシサーバー」の表示の他に、ドメインの国制限が設定されている場合には、「日本以外」や「日米以外」の表示が行われます。
　また、アクセスがPOST METHODである場合にのみ、ユーザーIDが検査されて、これが送り返されない場合には「無効ユーザーID」の表示が行われ、LQアクセス制限ライブラリが作成したものではないユーザーIDを送り返して来た場合には「不正ユーザーID」の表示が行われます。

　６行目以降には、CGIの環境変数の中で必要と思われるものとその値の一覧が表示されます。
　「HTTP_USER_AGENT」には、アクセス相手が使用しているブラウザなどの種類が表示されます。
　「HTTP_REFERER」には、参照元のURLが表示されます。このURLのページに、あなたのCGIへのリンクが存在する可能性があります（存在しない場合もある）。また、検索サイトに登録されている場合には、そのサイトのURLと共に、その末尾に検索に使用した文字が表示される場合もあります。
　「HTTP_COOKIE」には、アクセス相手から送り返されたクッキーが表示されます。この例では、「PETIT=」の後が掲示板CGIで設定したクッキーで、「プチ」という名前で投稿していることが分かるので、ここを見て誰のアクセスかを判断できる場合もあります。また、「CRU=」以降がこのライブラリで設定したユーザーIDのクッキーとなります。

　なお、ここに全く環境変数が表示されない場合もありますが、表示対象となる環境変数がなかっただけであり、異常ではありません。
環境変数環境変数の値
HTTP_COOKIEPETIT=name:プチ,email:live@a.biglobe.ne.jp,url:,pwd:del,color:800000; CRU=Unyk374
HTTP_REFERERhttp://www.googol.com/search?q=CGI
HTTP_USER_AGENTMozilla/4.0 (compatible; MSIE 5.0; Windows 98)

　また、プロキシサーバー経由のアクセスの場合には、下のように、プロキシサーバー特有の環境変数が表示されることがあります。
　この例は、プロバイダが提供するプロキシサーバーの使用例なので、「HTTP_X_FORWARDED_FOR」に本来の接続元のIPアドレスが表れています。 このライブラリでは、CGIの環境変数にIPアドレスらしきものが漏れている場合には、そのホスト名も取得して色を変えて表示します（IP1A0634.osk.mesh.ad.jpの部分）。
環境変数環境変数の値
HTTP_COOKIEPETIT=name:プチ,email:live@a.biglobe.ne.jp,url:,pwd:del,color:800000; CRU=Unyk374
HTTP_USER_AGENTMozilla/4.73 [ja] (Win98; U)
HTTP_X_FORWARDED_FOR211.13.26.126IP1A0634.osk.mesh.ad.jp
HTTP_CACHE_CONTROLMax-age=259200
HTTP_VIA1.0 proxy03.biglobe.ne.jp:8080 (Squid/1.1.11)

　最後の行では、このアクセスに対する各種のアクセス制限の登録が簡単にできるようになっています（新規登録ページでも登録は可能です）。
　ホスト名をアクセス禁止にする場合には（禁止ホスト名）、通常は、入力欄に予め入力されたホスト名を編集してからボタンをクリックして「禁止ホスト名」の登録を実行して下さい。
　なお、このホスト名にIPアドレスが表示されている場合には、ホスト名が取得できていないので、「禁止ホスト名」の登録は無意味です。
　その他のアクセス制限（禁止IPアドレスと禁止ユーザーIDと許可ユーザーIDと許可IPアドレス）は、それぞれのボタンをクリックするだけで登録されます。
　各アクセス制限の詳細は、[HELP]のリンクをクリックして、このHELPページの該当項目を参照して下さい。 このHELPページは、「HELP」という名前のウィンドウに表示されます（新規にウィンドウを開く場合もあるし、既存のウィンドウに表示される場合もあります）。
　なお、ホスト名が設定されていないアクセスの場合には、「ホスト名」の登録欄は表示されません。 また、ユーザーIDが設定されていないアクセスの場合には、「ユーザーID」の登録欄は表示されません。
[HELP]
 ホスト名 の
[HELP]
 IPアドレス [211.13.26.126] の
[HELP]
 アクセス禁止の有効期限　 30日 90日 180日 360日
[HELP]
 ユーザーID [Unyk374] の
[HELP]
 ユーザーID [Unyk374] の
[HELP]
 IPアドレス [211.13.26.126] の

公開プロキシサーバーからのアクセス制限

　誰でもが自由に利用することができるプロキシサーバーを、ここでは「公開プロキシサーバー」と言うことにします。
　このような公開プロキシサーバーを使用すると、本来のアクセス元となる契約プロバイダなどのIPアドレスを隠すことができるので、荒らしがアクセスを匿名化するためによく利用します。(*1)

　インターネット上にこのような公開プロキシサーバーがいくつあるのかは分かりませんが、少なくとも数千を超えることは確かでしょう。(*2)
　従って、公開プロキシサーバーを経由して荒らしからのアタックを受けた場合に、このIPアドレスを禁止IPアドレスに登録してアクセスを禁止したとしても、相手は直ぐに別の公開プロキシサーバーに切り替えるので、キリがありません。
　このため、多数の公開プロキシサーバーを自在に利用する手馴れた荒らしに対処することは、なかなか容易なことではありません。
　しかしながら、CGIを設置している側の状況さえ許せば、このような公開プロキシサーバーからのアクセスを効率よく制限することはできるので、あせることなく的確に、また、場合によっては根気良く対応することにより、荒らしを撃退することは必ず可能です。

　LQアクセス制限ライブラリでは、このような公開プロキシサーバーからのアクセスを制限するために、以下の３種類のアクセス制限方法を用います。 　CGIを設置しているホームページの環境や状況によっては、上記プロキシサーバー制限やドメインの国制限が利用できない場合もありますが、これらのアクセス制限が利用可能であれば、わずかな禁止IPアドレスの登録を行うだけで、公開プロキシサーバーからのアクセスは確実に制限できるようになります。

(*1) プロキシサーバーは、歴史的には種々の目的で使用されていましたし、現在でもファイアーウォールを超えるためや、キャッシュによるアクセスの効率化を図るために利用されています。 従って、プロキシサーバーからのアクセスが全て不正なアクセス目的であるとは限りません。
　例えば、会社や学校などでLANを構築している場合、外部からの不正なアクセスを防ぐために、インターネットとの間にファイアーウォールを設けるのが一般的であり、このために内部のLANからインターネットにアクセスする際には、プロキシサーバーを利用してファイアーウォールを超える必要があります。 このようなプロキシサーバーの利用は、インターネットにアクセスする際には避けられないものであり、そのLANなどの特定のドメイン内からの利用に限られるので、匿名性ともかかわりのない正当なものです。
　これに対して、公開プロキシサーバーは、使用の必然性がなく、しかも、誰でもが利用できるものであるため、不正な目的に利用されることになるのです。

(*2) 公開プロキシサーバーは、一方で既存のものがどんどん利用できなくなるのに対して、他方では新たなものもどんどん利用可能になっているので、実際にいくつあるのかを数えることは実質上ムリです。

(*3) プロキシサーバー制限とドメインの国制限を使っても制限できない公開プロキシサーバーを荒らしが探し出すには、（たとえ他人が見つけて来たものを利用するだけでも）それなりの労力が必要となります。 これに対して、禁止IPアドレスの登録は、送信ボタンのクリックだけで済む簡単な作業です。
　このため、もし悪質な荒らしに狙われて、何度禁止IPアドレスを登録しても、直ぐに新たな公開プロキシサーバーを使ってアクセスして来るように見える場合であっても、実際には、登録のたびに荒らしの手持ちの貴重な公開プロキシサーバーのリストがどんどん減っているのが実情なのです。 また、荒らしにとっては、安心して利用できると判っている公開プロキシサーバーは、普段使い慣れたものに限られるので（ホントに安心して利用できると確認しているかどうかも怪しいかも…？）、新しい公開プロキシサーバーを次々に変えて利用することには不安もあるハズです（そのような不安を現実のものにしてあげるかどうかは、貴方のお随意にどうぞ…LQアクセス制限ライブラリでは一切関知致しません）。
　従って、地道に対応していれば、禁止IPアドレスの登録の手間は必ず報われるハズです。

IPアドレスとホスト名

　IPアドレスは、インターネット上のサイトを識別するための住所のようなもので、ここでは主にCGIにアクセスして来た相手の接続元の意味で使用します。
　このIPアドレスは、実際は32ビット(*1)の数値（0〜4294967295の範囲）ですが、通常は、これをドットで区切った8ビットずつの４つの数値（0〜255の範囲）に分けて、例えば
211.128.56.15
のように表記します。

　CGIにアクセスして来た相手に関する種々の情報は、WebサーバーがCGIの環境変数に設定しますが、この情報の中では、IPアドレス(*2)だけが、唯一誤魔化しようのない確実なもので(*3)、他はアクセス元のクライアントが自主申告するもの(*4)であるため、必ずしも信用ならない場合があります。
　ただし、プロキシサーバーを経由してアクセスして来た場合には、アクセス元のIPアドレスがこのプロキシサーバー自身のものとなるため、プロキシサーバーにアクセスを依頼した本来のアクセス元のIPアドレスを隠蔽することが可能となります。
　また、CGIを設置したサーバー内にアカウントを持つ他人が直接アクセスしてきた場合には、このIPアドレスは無意味なものとなります。（「同一サーバー内からの不正アクセス」を参照）

　ホスト名(*5)は、単なる数値であるIPアドレスに付けた名前のようなもので、特定のIPアドレスにどのようなホスト名が対応するかは、DNS（Domain Name System）に設定されます。 通常は、これらは同じものだと思っても支障はないでしょう。
　このため、アクセス元を識別するためには、IPアドレスだけを使えばよいのですが、ホスト名は、それを見るだけで、国名やプロバイダなどが判るので、禁止ホスト名などでは、IPアドレスに代えてこのホスト名でアクセス元を識別します。

　なお、全てのIPアドレスにホスト名が対応付けられているとは限りません。 つまり、DNSに設定されていないIPアドレスには、ホスト名がありません。
アクセスログページでは、ホスト名がない場合のホスト名の欄に「？」と表示します。
　ちなみに、ホスト名のないIPアドレスからのアクセスが全て怪しいとは限りません。
(*1) 最近ではIPアドレスが不足しているため、将来は128ビット(IPv6)に拡張されます。

(*2) 他にホスト名やポート番号も確実なものではありますが、ホスト名はIPアドレスと同等であり、ポート番号はここでは特に意味がないので、省略しています。

(*3) クラッカー（マスコミなどで「ハッカー」と言われることが多い）の技術を用いれば、このIPアドレスを誤魔化したり、踏み台などを使って隠蔽することはできます。 しかし、このようなクラッキング技術は、いろいろな意味でコストの高いものであるため、荒らしなどに用いられることはまずないと思われます（荒らしに使うには勿体無い…？）。 もし、掲示板などでIPアドレスを誤魔化しているとしか思えないような事例があったとすれば、「同一サーバー内からの不正アクセス」の可能性を疑った方がいいでしょう。

(*4) アクセス元のブラウザの種類や参照元など種々の情報を送って来ます。

(*5) リモートホスト、ドメイン名、FQDNなどと呼ばれることもあります。

同一サーバー内からの不正アクセス

　ホームページへの不正アクセスには、インターネットを経由したHTTPによるアクセス（ブラウザなどによる通常のアクセス）の他に、同一のサーバー内からのものもあります。
　同一のサーバー内というのは、サーバー機（サーバーとして用いているコンピューター）が同じであるという意味です(*1)。
　例えばあなたのホームページがプロバイダから提供されたサーバー機のハードディスク内に設置されている場合、同じハードディスク内には、そのプロバイダと契約している他の人のホームページも設置されています。 しかも、大手のプロバイダの場合には、数千〜数万の赤の他人のホームページが同居しています。
　このような同一サーバー内の同居人は、例えば自分のホームページに設置したCGIを使ってインターネットを経由せずに直接あなたのホームページにアクセスすることもできます。 同居人が自分のCGIにアクセスする際にはインターネットを経由することになりますが、そのCGIからあなたのホームページにアクセスする際には、サーバー機のＯＳ上の通常のファイルアクセスとしてアクセスすることになるのです。
　つまり、このような同居人は、あなたのホームページに設置されたCGIのファイル内容を閲覧することができますし、このCGIのデータファイルの内容を閲覧することはもちろん、これを書き換えたり削除したりすることもできてしまいます。

　ただし、あなたのホームページのサーバーがCGIを所有者権限(*2)で動作させる場合には、ファイルのパーミッションを適正に設定している限り、このような同居人からのファイルアクセスを確実に排除することができます。
　しかし、CGIが所有者権限で動作するサーバーは、多くなったとはいえ、まだ一般的ではありません。 このため、CGIが所有者以外の権限で動作する場合には、このような同居人からのアクセスを防ぐ方法がなく、悪意のある同居人がいた場合には、プロバイダの管理人に相談する他、対処のしようがありません（このライブラリも全く無力です）。特に、無料でホームページを提供するようなサーバーでは、このサーバーの管理人でさえも、利用者が具体的に誰であるかを把握できない場合があります。

(*1) 「サーバー」という言葉は、UNIXなどでのApache（アパッチ）やWindows NTでのIISなどのWebサーバー（WWWサーバー／httpd）や、FTPサーバー（ftpd）などのようなソフトウエアとしてのサーバーの他に、これらソフトウエアのサーバーを稼動させるハードウエアのサーバー（サーバー機）という意味でも用いられます。 また、両方どっち付かずの意味で用いられることもあり、双方を含んだ全体としての意味で用いられることもあります。

(*2) あなたのホームページのCGIがどのような権限で動作するかは、このライブラリのCGIの最初の起動時に表示されます。 所有者権限で動作する場合には、「所有者権限で実行されます。」と表示され、その他の権限で動作する場合には、「普通の権限で実行されます。」と表示されます。

CGIの環境変数

　CGIの環境変数というと、親プロセスであるWebサーバーが設定した環境変数の全てということになりますが、ここでは、アクセス元に関係する情報に限定しているので、以下に示す環境変数の意味で使用します。

ホームページ

　ここでは、個人や組織が管理、運営、主催するWebサイトの意味で使用しています。
　ブラウザの起動時に表示されるWebページや、ホストのドキュメントルートのデフォルトページではありません。

　このWebサイトにLQアクセス制限ライブラリを組み込んだCGIを設置したりします。

プロバイダ

　Provider じゃぁ漠然としすぎているので、今はISP(Internet Service Provider)という表現の方が一般的なのかな…？
　法的な定義は知らないので、細かいことは抜きにして、ここでは、インターネットへの接続のサービスを行う業者ということで、電話回線を使う一般的なプロバイダの他、ケーブルTVのインターネット接続サービスなども含めた広い意味で受け取って下さい。

GET METHODとPOST METHOD

　例えばブラウザでCGIにアクセスする場合のアクセス方法（METHOD）には、GET METHODとPOST METHODとがあります（他にもあるけど、ここでは省略）。
　掲示板CGIでは、多くの場合、投稿内容の参照はGET METHODで行ない、投稿は、POST METHODで行ないます(*1)。 また、投稿内容の削除やこの投稿内容が複数ページにわたる場合の次ページへの移動もPOST METHODで行なうことが多いです。

　このGET METHODとPOST METHODの見分け方は、HTMLソースを見れば一目瞭然なのですが(*2)、ブラウザの操作時に明確に見分けるのは必ずしも簡単であるとは限らないようです。
　一般には、Webページの参照はGET METHODで、CGIなどにデータを送る場合にはPOST METHODとなることが多いのですが、GET METHODでも、URLに ? を付けてその後にデータを付加することが出来ますし(*3)、POST METHODで参照だけを行なうことも可能なので、必ずしもこれだけで区別はできません(*4)。
　<A>タグのリンクを辿ってやって来るアクセスは全てGET METHODです(*5)。
　送信ボタンを押してアクセスする場合の多くは、POST METHODですが、GET METHODの場合もあります。 送信ボタンを押した後にダイアログボックスが現れるのがPOST METHODだという話もありますが、これもブラウザの設定によりますし、最近のインターネット・エクスプローラは、規定値ではダイアログボックスが出ないようなので、これもアテにはなりません。

　ただし、最近の多くの掲示板CGIなどでは、参照だけならGET METHOD、投稿や削除などの内容の変更に関わるより重要な操作はPOST METHODで行なうことが多いので、LQアクセス制限ライブラリでも、GET METHODに比べてPOST METHODの方が厳しいアクセス制限を課すことができるようにしています。(*6)
　このため、GET METHODとPOST METHODの使い分けが通常とは異なるCGIでは、アクセス制限を行なう場合に注意が必要になることもあります。

(*1) 古い掲示板CGIでは、GET METHODによる投稿を受け付けるものもあったために、イメージタグ攻撃の標的にされることがありました。

(*2) <FORM>タグで METHOD=POST の属性が指定されたものだけが、POST METHODとなります。

(*3) 検索ページなどでブラウザのアドレス欄のURLの後ろの方にいろいろ訳の判らない文字が付くことがありますが、あれがGET METHODで送られるデータです。
　このGET METHODで送って来たデータは、アクセスログページの「環境変数」の欄の「QUERY_STRING」の値に表示されます。

(*4) GET METHODもPOST METHODも同じことができるのに、なぜ２種類のアクセス方法があるのかというと、GET METHODではデータをURLにくっ付けて送るために、あまり大きなデータを送ることができないという制約があったことから、後にPOST METHODが追加されたという経緯があるためです。

(*5) ちなみに、イメージタグ攻撃で使用される<IMG>タグの SRC 属性で指定されたURLへのアクセスもGET METHODとなります。

(*6) CGIの環境変数の CONTENT_LENGTH を参照して、POST METHODで実際にデータが送信されて来たかどうかを調べる方法もありますが、空POSTを使用することはほとんどないと思われるので、この方法は採用していません。

ブラウザ

　Webクライアント（WWWクライアント、HTMLクライアント）の一種で、HTMLを解釈して、それに応じたレイアウトでWebページを表示するソフトウエアのことです。 Webクライアントという場合には、Webサーバーにアクセスする全てのソフトウエアをいい、ブラウザとは異なりWebページを表示するとは限りません。
…と言って分かるなら、この項は見てないハズなんですが…
　要は、インターネットエクスプローラ（IE）やネットスケープナビゲータ（NN/NC）などのことを意味します。 特に、ここでは、あなたのホームページにアクセスして来た相手が使用しているインターネットエクスプローラやネットスケープナビゲータなどのことです。
　このブラウザには、その他に、各種のものがあり、特殊なものとしては、アプリケーションに付属のブラウザやインターネット対応のゲーム機／ワープロ専用機で使用するものや、i-modeなどの携帯電話で用いるものなどがあります。
　ブラウザではないWebクライアントとしては、検索ロボットなどがよく知られていますが、最近では掲示板CGIの更新状況を調べるサイトチェッカーなどもよく見掛けるようになりました。 また、荒らしが使用する自動投稿ツールなども、このWebクライアントの一種です。
　ちなみに、プロキシサーバーは、WebサーバーとWebクライアントの双方の機能を持っていて、Webサーバー機能によって本来のアクセス元からのアクセス要求を受け取り、Webクライアント機能によってあなたのホームページに代理でアクセスして来ます。

　ユーザーIDを利用する場合には、このブラウザがクッキーに対応しているかどうかが問題になります。
　アクセス相手が使用しているブラウザ（Webクライアント）の種類は、アクセスログページの「環境変数」の欄の「HTTP_USER_AGENT」の値に表示されます。

許可ユーザーID

　許可ユーザーIDを登録することにより、他のアクセス制限によってアクセスが禁止される場合であっても、このユーザーIDが設定された相手からのアクセスだけは許可します。 つまり、そのIPアドレスやホスト名が以下のアクセス制限の登録や設定に該当する場合にも、アクセスを禁止しません。

　許可ユーザーIDの登録を有効にするには、ユーザーIDを送るクッキーの名前の設定で名前を設定する必要があります。
　また、アクセスの相手が使用するブラウザも、クッキーの受け付けが可能でなければなりません。

　この許可ユーザーIDに該当するアクセスは、他の全てのアクセス制限に優先してアクセスを許可するので、禁止ホスト名の登録によってプロバイダの特定のアクセスポイントからのアクセスを一律に禁止した場合や、プロキシサーバー制限を設定してプロキシサーバーからのアクセスを一律に禁止した場合などに、これらのアクセス制限に該当する中の特定の相手だけのアクセスを許可することができます。
　なお、プロキシサーバー制限を設定してるときに、会社や学校などからプロキシサーバー経由でなければアクセスできない人のアクセスを許可するには、通常はこの許可ユーザーIDを用いるよりは、許可IPアドレスの方が確実です。
　従って、この許可ユーザーIDは、同一地域内の人が多くアクセスするホームページのように、同一プロバイダの同一アクセスポイントを利用する人が多いサイトで、その中の特定の人のアクセスを禁止する場合に用いるのが効果的でしょう。
　同一プロバイダの同一アクセスポイントからのアクセスは、同じドメイン内のIPアドレスを共用するので、これをアクセスする相手ごとに区別することは困難です(*1)。 そこで、アクセスを禁止したい相手に禁止ユーザーIDを登録して排除できれば問題はないのですが、少しパソコンの知識のある相手にはクッキーを用いたアクセス制限は効果がありません。 そこで、まずそのアクセスポイントを利用する他の人にこの許可ユーザーIDを登録しておき(*2)、次にそのアクセスポイントを禁止ホスト名の登録を行って一律にアクセス禁止にすれば、許可ユーザーIDが登録されていない相手のアクセスだけを禁止することができます(*3)。
　ただし、そのアクセスポイントを利用して新規にアクセスして来る人も排除されるので、この場合は、何らかの方法でその相手と連絡を取り、事後的に許可ユーザーIDを登録するほかありません。

　なお、同じユーザーIDに対して、この許可ユーザーIDと禁止ユーザーIDを重複して登録することはできません。 後で登録した方だけが有効となり、先の登録は削除されます。

(*1) ブラウザ（User-Agent）の種類などによって区別する方法も考えられますが、このライブラリでは、そのような区別の方法は採用していません。
　実際、こうIEが多くなると、どれほど効果があるかが疑問でもありますし…

(*2) UG系のサイトでないかぎり、普通はクッキーが使えるでしょうし、アクセスを許可する方の相手とは信頼関係もあるでしょう。

(*3) 禁止範囲内のIPアドレスで「0.0.0.0 〜 255.255.255.255」の全範囲のIPアドレスの登録を行うと、全てのアクセスを禁止することができます。 そこで、特定の人だけに許可ユーザーIDの登録を行えば、簡単な会員限定のCGIとすることができます。
　ただし、会員の登録の手続きやその削除操作などの管理は、専用の会員制CGIに比べて面倒なものになりそうです。

禁止ユーザーID

　禁止ユーザーIDを登録することにより、このユーザーIDが設定された相手からのアクセスだけを禁止します。

　禁止ユーザーIDの登録を有効にするには、ユーザーIDを送るクッキーの名前の設定で名前を設定する必要があります。
　また、アクセスの相手が使用するブラウザも、クッキーの受け付けが可能でなければなりません。

　この禁止ユーザーIDに該当するアクセスは、許可IPアドレスが登録されている場合にも、これに優先してアクセスを禁止します（ユーザーIDを用いたアクセスの許可／禁止は、アクセス制限の中で最も優先されます）。

　この禁止ユーザーIDの登録によるアクセス制限は、特定の相手（実際にはブラウザなどのクライアント）だけを限定して制限できるので、他のアクセス制限のように、無関係の他人を巻き添えにするような問題が生じない理想的なアクセス制限方法です。

　ただ、ユーザーIDは、クッキーを利用するので、管理人とアクセス相手との信頼関係がなければ、正しい認証を行うことができません。 しかし、掲示板荒らしなどの常習者にこのような信頼関係を期待することは当然不可能です。 また、このような常習者ではなくても、クッキーを利用してアクセス制限を行っていることがバレると、簡単に回避されてしまいます。 自分が受け取ったクッキーを調べることができる人ならば、どのようにアクセス制限されたかを推測することも容易です。
　つまり、禁止ユーザーIDによるアクセス制限は、相手の無知に付け込むアクセス制限方法にすぎないので、この禁止ユーザーIDでアクセス制限できれば「ラッキ〜！」くらいに考えて、あまり過度の期待はしない方がいいでしょう（苦笑）

…とは言うものの、最近は、単純な荒らし行為も横行しているので、UG系以外のホームページでは、他人に迷惑をかけないという大きな利点があることから、この禁止ユーザーIDによるアクセス制限を利用しても損はないでしょう（笑い）

　なお、他のアクセス制限でも同様ですが、特にこの禁止ユーザーIDによるアクセス制限では、上記のようにクッキーを使っていることがバレると簡単に回避されるので、アクセス制限の方法を相手に知られないようにする必要があります。
　アクセス制限が成功した後で、相手の無知を揶揄するような行為は、もってのほかです。 自宅のパソコンでアクセス制限を受けた相手も、友人の家や学校、会社などのパソコンを利用すれば、また簡単にアクセスすることはできるのです。

　なお、同じユーザーIDに対して、この禁止ユーザーIDと許可ユーザーIDを重複して登録することはできません。 後で登録した方だけが有効となり、先の登録は削除されます。

ユーザーID

　ユーザーIDは、アクセスの相手を識別するための符号であり、このライブラリを組み込んだCGIがアクセスの際にその相手のブラウザなどにクッキーを送ることによって設定します。 そして、この相手のブラウザなどが以降のアクセスの際に、同じクッキーを送り返して来ることにより、このクッキーに設定したユーザーIDを用いて相手を識別することが可能となります。
　従って、ユーザーIDが設定できるのは、相手が、インターネット・エクスプローラやネットスケープ・ナビゲータなどのようにクッキーに対応したブラウザを使用している場合に限られます。 しかも、このようなブラウザを使用していても、クッキーを受け付けないようにすることは可能なので、このような場合にもユーザーIDを設定することができません。
　また、その相手が自宅のパソコンから会社や学校などのパソコンに変更してアクセスして来た場合はもちろん、同じパソコンでも、異なる種類のブラウザを利用したような場合にも、別人であると判断されるので注意して下さい。
　さらに、クッキーには、有効期限があるので、この期間全くアクセスがない場合には、設定したユーザーIDも消滅してしまいます。

　ユーザーIDを用いたアクセス制限を利用するには、ユーザーIDを送るクッキーの名前の設定で名前を設定する必要があります。

　アクセス相手がユーザーIDを送り返してアクセスして来た場合、同じユーザーIDを送って有効期限を更新します。
　アクセス相手が新規の訪問者かクッキーを受け付けない相手であって、ユーザーIDを送り返して来ない場合には、新たなユーザーIDを生成して送ると共に、このユーザーIDのカウント値をカウントアップします。 ただし、同じIPアドレスで連続アクセスして来た場合には、正規のユーザーIDを新規に次々と発行する無駄を防止するために、ユーザーIDの発行を停止します。

　アクセスログページでは、各アクセスの「ID」の欄（「IPアドレス」欄の右側）に、ユーザーIDが表示されます。 この欄が英数字ではなく「-」となっている場合には、クライアントにユーザーIDが設定されていないことを示します。
　なお、初めてアクセスして来た相手は、必ず「ID」欄が「-」となり、クッキーが受け付けられれば、次回以降のアクセス時にユーザーIDが表示されます。

　ユーザーIDは、前半の４桁の英数字と、中央の２桁の英字（大文字と小文字）と、後半の１桁以上の数値からなります。 後半の数値は、このライブラリを組み込んだCGIへのアクセスの順に付与されるカウント値ですが、アクセスログファイルが壊れると、数値はリセットされます。 前半の４桁の英数字は、後半の数値からユーザーIDの鍵と塩を用いて生成した一方向ハッシュ値です。 これにより、ユーザーIDが正規のものかどうかを検査するので、ユーザーIDの鍵と塩は秘密にしておく必要があります(*1)。 中央の２桁の英字は、ユーザーIDの作成時にランダムに発生させたものであり、後半の数値がリセットされて重複した場合の偶然一致の可能性を減らすために付加しています。
　また、アクセスログページの最初の部分に表示される「LAST ID」は、最も最近に設定したユーザーIDの後半の数値です。 この「LAST ID」の数値は、同じアクセスの相手を１回しかカウントしないので、アクセス回数ではなく、訪問者の総数を表すものとなります。 ただし、クッキーを受け付けない相手はアクセスのたびにカウントされるし、クッキーの有効期間内にアクセスがない場合にはユーザーIDが更新されるので、必ずしも正確なものではありません。
　なお、ユーザーIDを使用しない場合には、単なるアクセスカウンタとなります。

(*1) クッキーのユーザーIDを用いてアクセス相手の認証を行う場合、アクセスの相手は、このユーザーIDを勝手に書き換えて送り返すことができるということに注意する必要があります。
　このため、LQアクセス制限ライブラリで使用するユーザーIDは、一方向ハッシュ値により、簡単にはユーザーIDを偽造できないようにしています(*2)。 つまり、後半の数値とユーザーIDの鍵と塩からcryptを使用して前半の英数字を生成しているので、普通には、この後半の数値と前半の英数字の正しい組み合わせを予測できないようになっています。
　従って、CGIの管理人は、ダウンロード時に設定されたユーザーIDの鍵と塩を他人に知られないようにする必要があります。 また、CGIの管理人だけでなく、アクセスして来た人も自分自身のユーザーIDを他人に教えてはいけません。
　このユーザーIDに限らず、クッキーによって設定される情報は、サイトの管理人とその特定のアクセス相手だけが知り得る秘密の情報です。

(*2) ただし、自分が受け取ったユーザーIDの後半の数値と前半の英数字は正しい組み合わせであることが保証されるので、クッキーを送らないようにしてアクセスを繰り返すことにより、多数の正規のユーザーIDを取得することは可能です。 このため、ユーザーIDによるPOST制限を設定する際には、ユーザーIDの新規発行の停止も同時に行う必要が生じます。

許可IPアドレス

　許可IPアドレスを登録することにより、そのIPアドレスからのアクセスを優先的に許可します。
つまり、そのIPアドレスやホスト名が以下のアクセス制限の登録に該当する場合にも、 アクセスを禁止しません。
ただし、許可IPアドレスを登録したIPアドレスからのアクセスであっても、 そのクライアントが禁止ユーザーIDに登録されたユーザーIDを設定されている場合には、 アクセスは禁止されます。

　この許可IPアドレスは、主にプロキシサーバー制限を設定した場合に、 特定のプロキシサーバー経由のアクセスを許可するために使用します。
　プロキシサーバー制限を設定した場合には、 特別のプロキシサーバーを除いて、ほとんどのプロキシサーバー経由の アクセスが一律に制限されます。 これは、プロキシサーバーを次々に変えてアクセスして来る 荒らしに対抗するための手段の一つなのですが、 このため、会社や学校からファイアーウォールのプロキシサーバーを 経由しなければインターネットにアクセスできない 無関係の人まで巻き添えとなって、アクセスを禁止されてしまいます。
　そこで、このような無関係の人が使用するプロキシサーバー （このプロキシサーバーは、通常は他人が勝手に利用できることはありません） のIPアドレスを許可IPアドレスとして登録することにより、アクセスを可能にします。
　実際には、アクセス制限を受けた人からの連絡を受けるか、 アクセスログページで「アクセス禁止」となったアクセスを探して、 個々に許可IPアドレスを登録する必要があるので、 できれば、実際にアクセス制限を実行する前に、アクセスログを参照して、 常連のアクセスに該当するものがあれば、 事前に登録しておく方がトラブルが少なくなるでしょう。

禁止ホスト名

　禁止ホスト名を登録することにより、これに該当するホスト名からのアクセスを禁止します。
　登録する禁止ホスト名は、実際のホスト名の一部の文字列であってもかまいません。
　また、半角スペースで区切った複数の文字列を禁止ホスト名として登録した場合には、実際のホスト名が、これらの文字列を左から順に全て含む場合にのみアクセスを禁止します。

　この禁止ホスト名の登録は、主に特定のプロバイダの特定地域のアクセスポイントからのアクセスを制限する場合に使用します。
　ただし、この登録は、同じプロバイダの同地域のアクセスポイントを利用している無関係の多くの人のアクセスも同時に制限してしまうということに十分留意して下さい。
　プロバイダからのアクセスは、接続のたびにIPアドレスが変化するので、このIPアドレスを１個ずつ制限して行ったのでは面倒です。 しかし、IPアドレスが変化しても、ホスト名には共通の文字列が含まれるので、このホスト名に基づいて制限を行います。 また、プロバイダ全体を制限したのでは、特に大手のプロバイダの場合に、影響を受ける人が多くなるので、アクセスポイントのある地域を示す文字列も含めるようにして、影響を受ける人をできるだけ限定します。

　なお、プロバイダなどがホスト名を設定していない場合には、ドメインのIPアドレスを調べて、新規登録ページの禁止範囲内のIPアドレスを用いて制限を行います。
　例えば、以下のようにホスト名の先頭部分が変化するプロバイダからのアクセスを 制限する場合には、
p26-dn02marumaru.osaka.nbm.ne.jp
p04-dn03marumaru.osaka.nbm.ne.jp
p51-dn04marumaru.osaka.nbm.ne.jp
これらのホスト名で共通の後半の文字列を以下のように入力して、 禁止ホスト名として登録します。

この登録により、プロバイダNBM（仮名）の大阪府○○市のアクセスポイントから 接続して来たアクセスを禁止することができます。

　また、例えば、以下のようにホスト名の中間部分が変化するプロバイダからのアクセスを 禁止する場合に、
mrum2DS41.osk.knit.ad.jp
mrum3DS11.osk.knit.ad.jp
mrum4DS28.osk.knit.ad.jp
以下のような入力で登録すると、プロバイダKNIT（仮名）の大阪府下の全アクセスポイントから 接続して来た全てのアクセスを禁止してしまうことになり、 極めて多くの無関係の人が影響を受けることになります。

そこで、これらのホスト名で共通の前部と後部の文字列を１個以上の半角スペースで区切り、 以下のように入力して、禁止ホスト名として登録します。

この登録では、プロバイダKNITの大阪府○○市のアクセスポイントから 接続して来たアクセスのみを制限することができ、 影響を受ける無関係の人を絞り込むことができます。

　さらに、例えば、以下のようなホスト名のプロバイダからのアクセスを禁止したいが、
e834.osk03.ppp.hoge.or.jp
e764.osk06.ppp.hoge.or.jp
e504.osk04.ppp.hoge.or.jp
以下のようなホスト名のプロバイダからのアクセスは制限したくないというような場合には、
b411.osk06.ppp.hoge.or.jp
以下のように入力して、禁止ホスト名として登録します。

この登録により、プロバイダHOGE（仮名）の大阪府？市のアクセスポイントから 接続して来た前者のアクセスだけを制限することができます。
なお、先頭の 'e' の文字は、'.osk0' の文字列よりも前になければならないので、 この 'e' が 'hoge' の最後の文字にマッチして後者のアクセスまで制限される という心配は不要です。

　なお、アクセスログページで、この禁止ホスト名を登録する場合には、 以下のように、入力欄に予めホスト名が設定されているので、

このホスト名中の変化する文字を半角スペースに置き換えたり一部を削除して、 固定の文字列を少なくとも１個以上の半角スペースで区切ったものに 編集することにより、簡単に登録することができます。

禁止IPアドレス

　禁止IPアドレスを登録することにより、このIPアドレスからのアクセスを禁止します。
　アクセスログページでは、既にIPアドレスが設定されているので、そのままのボタンをクリックして下さい。
　新規登録ページでは、下記のように、0〜255の範囲の４つの10進数をドットで繋いだ形式でIPアドレスを入力します。

　IPアドレスについては、「IPアドレスとホスト名」を参照して下さい。

　この禁止IPアドレスは、最も基本的なアクセス制限の方法ですが、これで制限できるのは、常に同じIPアドレスからアクセスがある場合に限られるので、現実には、プロキシサーバーからの匿名のアクセスを制限する方法の一つとして使用することがほとんどです。 具体的な利用方法は、「公開プロキシサーバーからのアクセス制限」を参照して下さい。

禁止範囲内のIPアドレス

「新規登録ページ」でのみ登録可能

　特定のドメインからのアクセスを、連続するIPアドレスの範囲として制限します。

　このようなドメインは、通常は禁止ホスト名で制限すればよいのですが(*1)、ホスト名が設定されていない場合や、ホスト名では正確にドメインの範囲を特定できない場合に使用します。

　例えば、211.128.56.13 から 211.128.56.16 までの範囲内のIPアドレスを禁止するには、以下のように第１のIPアドレスと第２のIPアドレスによって範囲を指定して入力します。
〜
　この設定で、
211.128.56.13
211.128.56.14
211.128.56.15
211.128.56.16
の各IPアドレスを制限します。(*2)

　また、例えば、
211.128.55.〜
211.128.56.〜
211.128.57.〜
で始まるIPアドレスを全て制限するには、以下のように、値が最も小さいIPアドレスの最後を 0 にし（第１のIPアドレス）、値が最も大きいIPアドレスの最後を 255 にして（第２のIPアドレス）入力します。
〜

　なお、第１のIPアドレスと第２のIPアドレスは逆に入力してもかまいません（値の大きい方を第１のIPアドレスにしてもよい）。
(*1) …っていうか、プロバイダなどのアクセスを制限する場合にも、このIPアドレスの範囲で制限する方が本来なのですが、現実には、特定のアクセスポイントで与えられるIPアドレスの範囲が正確に分からない場合が多いために、禁止ホスト名で制限する方が便利なのです。

(*2) 逆に、211.128.56.13 から 211.128.56.16 までの範囲内のIPアドレスだけを許可するには、0.0.0.0 〜 211.128.56.12 と 211.128.56.17 〜 255.255.255.255 の２つの禁止範囲内のIPアドレスを登録します。

禁止ホスト名（正規表現）

「新規登録ページ」でのみ登録可能

　禁止ホスト名の正規表現にマッチするホスト名からのアクセスを禁止します。

　この禁止ホスト名（正規表現）は、新規登録ページでのみ登録可能です。

　ホスト名でアクセス制限する場合に、通常の禁止ホスト名よりも、正規表現を使って行いたいというマニア？の方のためのものです。
　perlの正規表現(VBScriptやJScriptの正規表現も同様)を自由に利用できる方以外には無用の長物でしょう。

アクセス禁止の有効期限

　以下のアクセス制限の登録には、登録日からの日数で有効期限が設定されます。
　禁止ホスト名の登録などでプロバイダの特定のアクセスポイントからのアクセスを禁止した場合、同じアクセスポイントを利用する他の無関係の人も排除されてしまいます。 このため、荒らしなどの騒動が治まれば、できるだけ早急にアクセス制限の登録を解除すべきです。
　また、公開プロキシサーバーは、ある程度期間が経過すると使用不可能になるのが通常なので、これを禁止IPアドレスとして登録しても、しばらくするとほとんどが無意味になります。
　さらに、アクセス制限の登録数が多くなると、処理効率が低下します。
　このため、古いアクセス制限の登録は、適宜整理を行った方がよく、不要な登録を簡単に削除するために、この有効期限を設けています。

　アクセス制限の期限は、登録後に既登録編集ページで延長や変更が可能なので、とりあえずは適当に選んで下さい。

　このアクセス制限の有効期限が切れるとアクセスは制限されなくなりますが、登録が自動的に削除されることはありません。 有効期限切れのアクセス制限の登録は、既登録編集ページを開いたときに自動的に削除ボックスにチェックが入るので、不要と判断した場合には、「登録削除」ボタンをクリックして削除して下さい。 ただし、まだアクセス制限が必要だと判断した場合には、その登録の「延長」ボタンをクリックして、有効期限を延長して下さい。

　なお、禁止ユーザーIDと許可ユーザーIDおよび許可IPアドレスには、有効期限がないので、必要に応じて既登録編集ページで削除して下さい。

アクセス制限の実行

「設定変更ページ」で設定

　以下のアクセス制限の登録に該当するアクセスを実際に制限するかどうかの設定を行います。
　なお、ここでの設定は、「繰り返しのPOSTアクセスの制限」の設定には影響を与えません。 つまり、「繰り返しのPOSTアクセスの制限」で秒数を設定した場合には、ここでの設定にかかわらず、該当するアクセスは禁止されます。

　この設定では、以下のいずれかを選択します。

アクセス制限時のステータスコード

「設定変更ページ」で設定

　アクセス制限を実際に実行した場合に、アクセスを禁止された相手に返すレスポンスのステータスコードを設定します。

アクセス制限時のファイルの設定

「設定変更ページ」で設定

　アクセス制限時に送るHTMLのメッセージを記述したファイルのパスを設定します。
　例えば、「forbidden.html」と指定した場合には、このライブラリを組み込んだCGIと同じディレクトリに設置した forbidden.html というファイルの内容を表示します。
　ここで指定したファイルの内容はHTMLでなければなりませんが、ファイル名や拡張子は任意です。

　アクセス制限時のステータスコードとの関係
　このファイルの中で、
<!-- DATE -->
というコメントを記述すると、アクセス日時の表示に変換され、
<!-- HOST -->
というコメントを記述すると、アクセス元のIPアドレスとホスト名の表示に変換されます。
　誤ってアクセスを制限された無関係の人にメッセージを送る場合には、この日時やIPアドレスなどを連絡して貰うことにより、アクセスログページで容易に確認し、アクセスを許可できるようになります。

　なお、この欄が未設定または不正な設定の場合には、適当なレスポンスメッセージを返します。

POST のみを処理対象

「設定変更ページ」で設定

　このライブラリの処理対象をPOST METHODによるアクセスだけに限定します。
　即ち、POST METHOD の場合だけアクセスログの記録を行い、POST METHOD の場合だけアクセス制限の対象とします。 従って、ここで「POSTに制限する」に設定した場合は、アクセス制限の実行で「全て制限する」に設定しても「POSTのみ制限する」に設定した場合と同じことになります。
　GET METHODによる閲覧者が多すぎる場合などに、「POST に制限する」の設定を行って下さい。

プロキシサーバー制限

「設定変更ページ」で設定

　プロキシサーバーからのアクセスを一律に禁止します。
　ただし、アクセスの際にプロキシサーバー特有のリクエストヘッダ（CGIの環境変数として設定される）を送って来たものだけを禁止するので、プロキシサーバーからのアクセスを全て禁止できる訳ではありません。
　公開プロキシサーバーを次々に替えてアクセスして来る荒らしを大雑把に排除するために使用します。 詳細は、「公開プロキシサーバーからのアクセス制限」を参照して下さい。
　会社や学校のように、プロキシサーバーを経由しなければインターネットにアクセスできない一般の人達もアクセスを禁止することになります。 このような場合は、そのプロキシサーバーのIPアドレスを許可IPアドレスとして登録することにより個別にアクセスを許可することができます。
　もっとも、会社や学校などからプロキシサーバー経由で新規の訪問者が頻繁にやって来るようなホームページでは、このアクセス制限を利用することはムツカシイでしょう。
　また、ホームページのサーバーがキャッシュサーバーを使用している場合には、このアクセス制限を利用することができません。

ドメインの国制限

「設定変更ページ」で設定

　ホスト名のドメインの国が日本（および米国）以外である場合にアクセスを禁止にします。(*1)
　公開プロキシサーバーの多くが外国に存在するものであるため、アクセスが日本からだけのホームページの場合に、プロキシサーバーを制限するために利用します。
　ただし、実際に外国からの一般のアクセスがあった場合にも、そのアクセスを禁止することになります。 このような場合は、その外国からのアクセスの相手にユーザーIDを設定して、これを許可ユーザーIDとして登録することにより個別にアクセスを許可することもできます。
　もっとも、海外から新規の訪問者が頻繁にやって来るようなホームページでは、このアクセス制限を利用することはムツカシイでしょう。
(*1) 国境のないインターネットには、およそふさわしくないアクセス制限ではありますが…(^^;
…まぁ、現実には、有効な場合があるので、荒らしに狙われた場合の一時的なアクセス制限として、状況が許すなら使用して下さい。

ユーザーIDを送るクッキーの名前の設定

「設定変更ページ」で設定

　ここでクッキーの名前を設定することにより、実際にCGIがユーザーIDのクッキーを送るようになります。
　禁止ユーザーIDや許可ユーザーID、ユーザーIDによるPOST制限を利用する場合には、事前にここで名前を設定しておく必要があります。

　クッキーの名前は、何でも良いと言えば、その通りなのですが、規定値は設けたくないので、例えば、あなたのホームページの名前などを利用して、簡単なものを設定して下さい(*1)。
　ただし、このライブラリを組み込んだCGIでもクッキーを設定する場合があるので、この名前と重複しないようにする必要があります。 このCGIがどのような名前のクッキーを設定するかは、掲示板CGIならテスト投稿するなどした後に、アクセスログページの環境変数の欄の「HTTP_COOKIE」の値を見て下さい。 ここで、例えば「PETIT=・・・」という値があれば、「PETIT」の部分がクッキーの名前になるので、この名前を避ければ、どのような名前でもかまいません。

　なお、この名前を変更すると、以前のユーザーIDは無効になるので、特別な事情がない限り変更しないで下さい。
　また、この名前には、日本語なども使用できますが、クエリー符号化のデコードを設定しないと、アクセスログページでは正しく表示されません。

　もしここで名前を設定してもユーザーIDが設定されず、「Set-Cookie: 」で始まるクッキーヘッダが本来のCGI出力の末尾に出力されてしまうような場合には、ユーザーIDのクッキー出力フラッシュを設定して下さい。

(*1) このクッキーの名前は、アクセス相手が自由に参照できるので、LQアクセス制限ライブラリのファイル名は使用しないで下さい （このファイル名のボディ部は、管理人の認証用に利用するので、ユーザーIDとして認識しません）。

ユーザーIDを送るクッキーの有効期限

「設定変更ページ」で設定

　ユーザーIDは、クッキーを用いて設定するので、有効期限の間アクセスがない場合には、ユーザーIDも消滅してしまいます。 特に許可ユーザーIDを用いてアクセスを許可している場合には、このユーザーIDが消滅するとアクセスが禁止されてしまうので、できるだけ十分な長さの日数を設定して下さい（規定値は90日）。
　禁止ユーザーIDのみを用いる場合には、他のアクセス制限の登録の有効期限と同様の期間を設定すればいいでしょう。

　なお、何らかの事情でクッキーのユーザーIDを消去しなければならない場合には、この有効期限に「-1」などの負の日数を設定します。

ユーザーIDによるPOST制限

「設定変更ページ」で設定

　POST METHODによるアクセスの際、正規のユーザーIDを送り返して来ない場合にアクセスを禁止します。
　禁止ユーザーIDは、クッキーを受け付けない相手には効果がないので、このような相手を最初から排除しておくために使用します。
　ただし、クッキーに対応していないブラウザを使用する無関係の人までPOST METHODによるアクセスができなくなるので、注意が必要です。 例えば、i-modeはクッキーが利用出来ません。また、ゲーム機やワープロ専用機などのブラウザを使用している場合も、クッキーが利用できない可能性があります。 つまり、実際には、アクセスして来る相手が全てインターネット・エクスプローラやネットスケープ・ナビゲータなどのクッキー対応のブラウザを使用し、このクッキーを利用しない設定を行わないような人達が集まるごく一般的なホームページでのみ利用可能となります。

　なお、禁止ユーザーIDを登録しても、相手が自分自身のクッキーを消去した場合には、LQアクセス制限ライブラリは新規にユーザーIDを発行するので、アクセスが可能になります。 このため、同時にユーザーIDの新規発行の停止も設定しなければならない場合があります。

ユーザーIDの新規発行の停止

「設定変更ページ」で設定

　ユーザーIDを送って来ないアクセスに対して、新規のユーザーIDを作成して送るのを停止します。
　ユーザーIDによるPOST制限を設定している場合に、禁止ユーザーIDを登録した相手が、自分自身のクッキーを消去することにより、新規のユーザーIDを取得するのを防止するために用います。
　なお、この相手が勝手に新規のユーザーIDを作成して送って来た場合には、「不正ユーザーID」としてアクセスが禁止されます。(*1)

　「ユーザーIDによるPOST制限」を設定して、この「ユーザーIDの新規発行の停止」も設定すると、既にユーザーIDが設定されている人のPOST METHODによるアクセスは許可されますが、新規にアクセスして来た人は排除されます （ただし、GET METHODによるアクセスはいずれも可能です）。 従って、この「ユーザーIDの新規発行の停止」は、非常時にのみ限定して設定を行うようにして、「新規訪問者の投稿はしばらくの間ご遠慮下さい」などのメッセージを表示しておくとよいでしょう。
(*1) このユーザーIDが不正かどうかの検査のために、ユーティリティCGIの最初の起動時に、ユーザーIDを作成するためのキーなどが自動生成されます。 このため、このとき作成された設定ファイル（ lqxxxxxx.cfg ）が壊れると、ユーザーIDの検査もできなくなるので、LQアクセス制限ライブラリの設置後には、設定ファイルをダウンロードしてバックアップにしておくことをお勧めします。

繰り返しのPOSTアクセスの制限

「設定変更ページ」で設定

　同一IPアドレスからのPOST METHODによるアクセスの常識を超える繰り返しを禁止します。

　掲示板などでは、通常は投稿記事の保存数が限られているので、無内容の投稿が繰り返されると、それまでの投稿記事が全て削除されてしまいます。 そこで、このアクセス制限の秒数を設定することにより、アクセスログに記録された同一IPアドレスのアクセスを検査して、POST METHOD によるアクセスの頻度が多すぎる場合に、このアクセスを禁止することができます。

　ただし、相手がIPアドレスを変更してさらにアクセスして来るのを防ぐことはできません。
　なお、掲示板などでは、次ページへの移動の場合などにも POST METHOD が使われることが多いので、相手が繰り返し投稿しようとしているとは限らないことに注意して下さい。 また、チャットのように、もともと短時間に繰り返し書き込みが行われるようなCGIの場合にも、このアクセス制限を用いることはできません。

　このアクセス制限は、アクセス制限の実行とは無関係に、秒数を設定した時点から有効となります。 特定の相手を制限するものとは異なり、チャットやその他の特殊なCGIの場合を除けば、念のため普段から設定しておいても問題はないでしょう。

　設定する秒数は、長いほど厳しい制限となります。
　下記の表では、例えば設定秒数が4秒の場合、同じIPアドレスでアクセスログに記録された POST METHOD による5回目のアクセスが、その中で最も古いアクセスから64秒以内であれば、そのアクセスが禁止されることになります。
つまり、この表は、連続投稿を行う場合に、その回数の投稿に要する時間を表すことになります。
各設定秒数でアクセスが制限される時間
アクセス回数＼設定時間2秒4秒6秒8秒10秒
2回目2秒以内4秒以内6秒以内8秒以内10秒以内
3回目8秒以内16秒以内24秒以内32秒以内40秒以内
4回目18秒以内36秒以内54秒以内72秒以内90秒以内
5回目32秒以内64秒以内96秒以内128秒以内160秒以内
10回目162秒以内324秒以内486秒以内648秒以内810秒以内
20回目約12分以内約24分以内約36分以内約48分以内約60分以内
50回目約80分以内約160分以内約240分以内約320分以内約400分以内

管理人の制限除外

「設定変更ページ」で設定

　このライブラリを組み込んだCGIの管理人にパスワードのクッキーを設定して、アクセスログの記録やアクセス制限を行わないようにします。
　管理人が使用するブラウザなどがクッキーを受け付け可能になっていない場合には、この機能を利用することができません。

　管理人は頻繁にアクセスを行うので、いちいちアクセスログに記録されたのでは鬱陶しい場合があります。 また、管理の都合上、頻繁にPOST METHODでアクセスしなければならないので、繰り返しのPOSTアクセスの制限の設定に引っ掛かる場合もあります。 このような場合に、「管理人を除外する」の設定を行います。

　なお、このクッキーは、実際には、このライブラリのユーティリティCGI（ lqxxxxxx.cgi ）が設定します(*1)。 また、有効期限は 90日です。このため、管理人を除外する場合には、何事もなくても、たまにはアクセスログを参照して、このクッキーの有効期限を更新するようにして下さい。
(*1) クッキーを送る際に PATH を設定しないので、ユーティリティCGI（ lqxxxxxx.cgi ）と同じディレクトリ（または、それ以下）にCGIが存在しなければ、このクッキーを受け取ることができません。
　逆に、ユーティリティCGIと同じディレクトリ（または、それ以下）に、誰でもが他人のクッキーを参照できるようなCGIを設置しないで下さい。

アクセスログの記録最大件数

「その他の設定変更ページ」で設定

　アクセスログに記録を残すアクセスの最大件数を設定します。
　なお、アクセスログページでは、このアクセスログに記録された全てのアクセスを複数のページに分けて表示することができます。

　このライブラリを組み込んだCGIへのアクセスの頻度に応じて、適当な件数を設定して下さい。

１ページに表示するアクセスの最大件数

「その他の設定変更ページ」で設定

　アクセスログページで１ページに表示するアクセスの最大件数を設定します。
　アクセスログの記録最大件数以下の数値を設定して下さい。 この記録最大件数と同数に設定すると、１ページに全てのアクセスが表示されます。

アクセスログに記録する環境変数の最大数の設定

「その他の設定変更ページ」で設定

　１件のアクセスに記録するCGIの環境変数の最大数を設定します。
　アクセスログには、CGIの環境変数の中で不要と思われるものを除いた残りが全て記録されます。 このため、一応念のため、この設定で記録数を制限しています。
　ただし、異常に小さい件数を設定した場合、所定の環境変数については、この制限を超えても記録します。

　規定値は 10件ですが、通常はこれを超えることはないので、特に変更の必要はありません。

アクセスログに記録する各環境変数の最大文字数の設定

「その他の設定変更ページ」で設定

　各CGIの環境変数の値を記録する際の最大文字数を設定します。
　アクセスログには、環境変数の値が全て記録されます。 このため、一応念のため、この設定で文字数を制限しています。

　規定値は 200文字ですが、これを超える場合はあまり意味のないものだと思われるので、特に変更の必要はありません。

クエリー符号化のデコード

「その他の設定変更ページ」で設定

　アクセスログページの環境変数の欄に表示するクッキー（HTTP_COOKIE）とクエリー文字列（QUERY_STRING）の値のクエリー符号化文字（%と英数字2文字）をデコードするかどうかを設定します。

　日本語のクッキーなどが読めない場合に「デコード」するに設定します。 だだし、日本語の文字コードが Shift-JIS とは異なる場合には、クエリー符号化の日本語文字コード変換の設定も行う必要があります。

クエリー符号化の日本語文字コード変換

「その他の設定変更ページ」で設定

　クエリー符号化のデコードでデコードした日本語の文字コードを Shift-JIS に変換するための設定です。
　ここに日本語文字コードライブラリである「jcode.pl」のパスを設定します。
　掲示板CGIなどで既に jcode.pl を利用している場合には、このファイルのパスを設定して下さい。

　なお、Shift-JIS 以外の文字コードを使用したい場合には、このライブラリのユーティリティCGI（ lqxxxxxx.cgi ）で使用する表示文字のコードを変換すると共に、この CGI ファイルの冒頭の
$Jcode = 'sjis';
の文字コードを対応するものに変更して下さい。

アクセス制限の登録に基づく検査

「その他の設定変更ページ」で設定

　現在のアクセス制限の設定や登録に基づいてアクセスログページの過去のアクセスについて検査を行うかどうかを設定します。
　アクセスログページでは、アクセス制限の設定／解除や登録／削除を行った場合に、すぐに効果が分かるように、過去のアクセスについても検査して、その結果を表示するようになっています。 しかし、アクセス制限の登録データが多くなりすぎると、負担の大きい処理になるので、もしサーバーエラーが頻発するような場合には、ここで「検査を行わない」の設定を行います。
　また、このような場合には、既登録編集ページで不要なアクセス制限の登録を調べて整理を行って下さい。

ホスト名の取得

「その他の設定変更ページ」で設定

　アクセスログページの「ホスト名」の欄に、全てのアクセスでホスト名が表示されない場合に、ここで「取得する」に設定します。
　「ホスト名」の欄に一部のアクセスでホスト名が表示されないことがあっても、それは異常ではありません。そのアクセスのIPアドレス自体にホスト名が設定されないことがあるからです。
　この「ホスト名」の欄にホスト名が表示されない場合には、禁止ホスト名などのアクセス制限を利用することができません。
　このライブラリの設置時に自動的にホスト名の取得が必要かどうかを検査するので、通常は変更は不要です。

アクセスログのファイルロック

「その他の設定変更ページ」で設定

　アクセスログの記録時に flock によるファイルロックを行うかどうかを設定します。

　このライブラリの設置時に自動的に flock が使用できるかどうかを検査するので、通常は変更は不要です。
　この検査で「ロックしない」と設定されたにもかかわらず、この設定を「ロックする」に変更した場合には、このライブラリを組み込んだCGIがサーバーエラーになる可能性があります。

時差の修正

「その他の設定変更ページ」で設定

　アクセスログページに表示されるアクセスの日時が実際の日時とずれる場合には、ここでその時間差を設定します。
　例えば、表示日時が実際の9時間前になる場合には「9」、9時間後の場合は「-9」に設定します。
　なお、ここでの設定は、CGIの環境変数TZには影響を与えません。

キャッシュサーバー

「その他の設定変更ページ」で設定

　このライブラリを組み込んだCGIの設置サイトがキャッシュサーバーを使用しているために、アクセス元のIPアドレスが取得できないことがある場合には、ここにキャッシュサーバーのIPアドレスを設定して下さい。

　キャッシュサーバーの設定が行われると、設定されたIPアドレスからのアクセスがあった場合に、CGIの環境変数HTTP_X_FORWARDED_FORの値の最後に設定されたIPアドレスを本来のアクセス元として扱います。 従って、本来のアクセス元がこのようにして取得することができないキャッシュサーバーの場合には、ここでの設定は無意味になり、このライブラリを有効に利用することができません。
　なお、キャッシュサーバーを使用しているサイトでは、このキャッシュサーバー自身がプロキシサーバーであるために、プロキシサーバー制限によるアクセス制限を利用することができません。

ユーザーIDのクッキー出力フラッシュ

「その他の設定変更ページ」で設定

　このライブラリを組み込むCGIが nkf（漢字変換ツール）を通して出力を行うような場合に、ユーザーIDのクッキーを送るようにすると、「Set-Cookie: 」で始まるクッキーヘッダが本来のCGI出力の末尾に出力されてしまう場合があります。
　このような場合には、ここで「フラッシュする」に設定して下さい。

　このライブラリでは、クッキーヘッダを print 文のデフォルトのファイルハンドル（STDOUT）に出力します。 しかし、CGIが他のファイルハンドルに出力を行う場合には、クッキーヘッダの出力の順序が狂ってしまう場合があります。
　そこで、「フラッシュする」に設定すると、クッキーヘッダの出力をフラッシュすることにより、バッファリングを行わないようにします。

外部POSTの禁止

「その他の設定変更ページ」で設定

　POST METHODによるアクセスの際に、ここで設定された URL 以下のページからのアクセスであるかどうかをCGIの環境変数HTTP_REFERERで検査して、外部からのアクセスの場合に、このアクセスを禁止します。

　このアクセス制限は、CGIが対応していない場合のための非常用のものです。(*1)
　従って、このライブラリを組み込むCGIが対応している場合は、ここでは設定せずに、CGI側で設定を行って下さい。
　なお、ここで設定が行われても、アクセスログページでは、この設定の基づくアクセス可否の検査は行いません。

(*1) このHTTP_REFERERの検査は、本来は、イメージタグ攻撃や自動連続投稿ツールへの対応が目的だったのですが、イメージタグ攻撃に関しては、ほとんどの掲示板などのCGIがGET METHODによる投稿を禁止することで解決したし、自動連続投稿ツールに関しては、ツール側でHTTP_REFERERの検査を回避できるように改造されたために、もはや無用の長物と化していました。
　しかしながら、最近は、どこの誰が作ったとも分からないWebサイトで、「投票してね」とかの送信ボタンを平気で押しまくるサルが多くなったという話も聞くので、念のためこのライブラリでも対応可能なようにしました。

<<<<<< LQアクセス制限ライブラリ >>>>>>