●● ブラウザで、 【クッキー】と【JavaScript】 を有効にしてある事が必要です。●● ＩＥ の場合は、　次の操作を行って、 JavaScript／Cookie を有効に設定して下さい。 ※ ＩＥを起動した状態で【設定変更】 した場合は、 一度　ＩＥ を終了した方が良かった 〜 かな ？。 【ＩＥを終了 ⇒ デスクトップのＩＥアイコン】で設定すれば確実でしょう。 　◇ブラウザを終了してから 設定を変更する人は、 　　この テキストの文章を　メモ帳などにコピーしてから ブラウザを終了しましょう。 ●デスクトップの 【Internet Explorer アイコン】 を右クリック　⇒　プロパティ⇒セキュリティ⇒インターネット選択⇒レベルのカスタマイズ ・・。 ●[ JavaScript の設定 ] １．【スクリプトを実行しても “安全” とマークされた ActiveXコントーロール】を有効にする。 ２．スクリプト --【アクティブスクリプト】を有効にする。（あるいは　ダイアログ表示） 　　　※ 【ダイアログ表示】 に設定した場合は、 ページが切り換わる度に　「スクリプトを有効にしますか？」 〜と質問されます。 　　　　　それに対して、１回でも　ＮＯ と答えると、let_JavaScript_ON.html のページに飛ばされます。 　◆MicrosoftＶＭ-- Javaの許可,,,「Javaを無効」でも良い。 　◆スクリプト--【Javaアプレットのスクリプト】は 無効でも良い。 　◆【スクリプトによる貼り付け処理の許可】　は 無効でも良い。 　◆その他の スクリプト関係の設定は、 全て“無効” もしくは 最高レベルの安全設定にしても、 閲覧に支障はありません。 ●[ Cookie の設定 ] 　◆【セッションごとの Cookie の使用許可（保存なし）】 を有効にする。 　◆【クッキー保存】 は、無効でも 有効でも 良し。　（ ← コンピュータに保存されている Cookie の使用許可） ＩＥ４ など、 【Cookieを受け入れる／受け入れない】の２つの選択肢しかない場合は、Cookieを受け入れる設定にする。 　◆注意 １ ． in_Top2.htm にも書いてあるように、　Cookieに【制限時間】を設定しています。 　※本家(IntrQ)サイトの in_Top2.htm を開いた時点から、４〜５時間が経過すると　freeDL.cgi を開けません。 　　freeDL.cgi を開いた後も、そのまま適用されます。 　　freeDL.cgi を読んでいる内に 時間が経過した場合は、in_Top2.htm を開き直して下さい。 　　　（あるいは、in_Top2.htm で【更新ボタン】を押す） 　　そうしませんと、 freeDL.cgi から【ダウンロードページ】に移行する前に 時間切れとなり、拒否されます。 　　　 （クッキー偽造の予防策） 　◆in_Top2.htmが送信するクッキーを　freeDL.cgiの先頭で 検査しますから、 　　in_Top2.htm を開いた後 ◆２〜３秒◆待ってから　freeDL.cgiを開いて下さい。 　◆注意 ２． freeDL.cgi を開いた後は、 freeDL.cgi配下のＣＧＩを実行するための Cookieの有効時間は １〜２時間となります。 　※freeDL.cgiの起動後に 別の【隠しＣＧＩ】が 追加で送信するクッキーの有効時間が１〜２時間。 　　　　　　　freeDL.cgi配下のＣＧＩで拒否された場合は、 freeDL.cgiを開き直せば　Cookieの有効時間が延長されます。 　　　　　　　ただし、 　　　　　　　in_Top2.htm を開いた時点からの制限時間は、そのままです。 　◆注意 ３． “本家サイトの in_Top2.htm”を開く前に　【Cookie設定】 が 無効だった人は、 　　　　　　　　　 Cookie の設定を変更した後、　in_Top2.htm を開き直す必要があります。 　　　　　　　その理由は、 　　　　　　　　“本家サイトの in_Top2.htm”が送信した 【暗号クッキー】 を、 freeDL.cgi が　あなたのブラウザから受信して検査するからです。 　　　　　　　　【Cookie保存】までは要求しませんが、 　　　　　　　　ブラウザが Cookieを受け付けない設定で “本家サイトの in_Top2.htm”を開いた人は、 送信した【暗号クッキー】が届いていません。 　　　　　　　　従って、 あなたのブラウザに対して 返信要求しても、返信されないのです。 　　　　　　　　同じ理由で、 　　　　　　　　ブラウザの 【オフライン】状態で in_Top2.htm を開いた人は、 freeDL.cgi を開けません。 　　　　　　　　　（その人は、ブラウザをオンライン状態にして　in_Top2.htm を開き直して下さい。） 　◆このテキストの最後に、【クッキーの制限・規約】について　説明してあります。 　　クッキーという物の意味を知らず、 なんとなく 不安を感じる人は、ササーっと読んで下さい。 　◆あなたのＰＣに クッキーファイルが書き込まれる事は ありません。◆２つのクッキーの 時間制限は、【analysis.cgi】によって実現しています。 ※ analysis.cgi のソースコード ↓ 　 http://www.interq.or.jp/jupiter/star3385/for_outer/guide_for_users/analysis.txt freeDL.cgiを開くための“ブラウザ設定”は、 ここまで読んで頂ければ大丈夫です。 　◆freeDL.cgi配下の 各ページ（CGI）と　【ページとページを中継する検問所】で、 さらに別のクッキー送信 と クッキー受信 を行っています。 　　時代劇に登場する 【関所の割符】 の役割を持たせています。 　　◇freeDL.cgi以降のＣＧＩで　ページ内容を表示するまで　少し時間がかかる事があります。 　　　各ページが　かなりの数のクッキーを 送・受信しているので、 これは 主に　サーバーとブラウザ間の【送信／受信】の時間です。 　　従って、サーバーの混み具合よりも　【ネットの混み具合】が ページ表示の所要時間に大きく影響します。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 以下は、参考事項です。 　◆２つのクッキー時間制限によって、 荒らし目的の【クッキー偽造／送信】に対して 防衛しています。 　　また、 暗号クッキーの送・受信によって、 　　【in_Top2.htm 以外からの“直リンク貼り”によるＣＧＩ起動】に対する保護機能を　２段構え としています。 　　“直リンク貼り”でＣＧＩを外部から起動させようとする人は、 　　『サーバーの負荷を上げて 誤動作させよう』〜 という目的で行います。 　　外部からの“直リンク”で数百回もの無為なＣＧＩ起動は、 私にとっても　一般の人々にとっても、 迷惑な話です。 　　外部からのリンクでＣＧＩが起動した場合は、クッキーの返信要求に対して　ブラウザは返信できるクッキーを持っていません。 　　クッキーを返信して来ないので、 　　【外部リンクの可能性あり】〜 と判断し、　サブのｐｌファイルを読み込む前に　早い段階で拒否します。 　　　（そのための【クッキー 送信・受信】です。） ●[ ファイルのダウンロード設定 ] 　◆インターネット−セキュリティレベルの設定で、【ファイルのダウンロード】という項目もあります。 　 これを 無効にしている人はいないでしょうが、 　 もし　これを“無効”の設定にしていると、どのサイトを訪問しても　何もダウンロード出来ませんよ。 ●参考までに、【MicrosoftＶＭ】の ＶＭ とは、 Virtual Machine（仮想マシン）の略です。 ウィルスや 不正なコードが実行される事について、ＩＥのセキュリティホールが報告され、 最近は　セキュリティアップデートを頻繁に行う必要がありますが、 上で登場した【MicrosoftＶＭ-- Javaの許可】の設定を　無効 にしておく方が安心です。 どうせ、人間が開発するものには　何かしら 欠陥はあります。 今後も　セキュリティホールは見つかるでしょう。 新技術というものは、人より先に勉強するのは良いことですが、 実際の利用については、 『本に書いてあるから・・あるいは、周りが使っているから 私も使おう』〜 という感覚では 人々が被害に遭う時は　自分も被害に遭うのです。 新しいものを積極的に使うということは、ある意味で【実験台】になるということです。 トラブルに遭遇した時に　自分で解決するための勉強を事前にしていない人は、イザという時に頭を抱えるだけです。 Virtual Machine とは　Windows心臓部の機能です。 私は、インターネットを使い始める時から、 『なに？、MicrosoftＶＭ ？・・Javaの許可だって？・・・こんな物は 無効にしておくに限る』〜 と考えていました。 　勉強するのがイヤな人は、インターネット専用に【中古のＰＣ】でも買い、 　そのＰＣには 大事なデータを入れないようにすれば良いのでは・・・(笑)。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ ◆余談ですが、クッキー と JavaScriptは 【荒らし対策】として使用しています。 ２ｃｈネラーは、情報の少ない特定のページを狙って【ウソの中傷】を行い、実情を知らない人々に対し、先入観を持たせます。 それらの行為から防衛する目的で　クッキー を使用しています。 つまり、 Cookieを必須条件にした事は、 外部ＢＢＳに“直リンク”を貼られることへの防止策です。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 万一　【クッキーファイル】を偽造される可能性を考えれば、 あなたのＰＣに【クッキーファイル】を保存すると、この場合は、　かえって　セキュリティ効果が低下します。 例えば、 クッキーの知識・技術に長けた人物が【クッキーファイル】を偽造し、それを　ネット上の共有フォルダに置いて、 「これをキミのＰＣの Cookiesフォルダにコピーしてから　http://〜〜/star3385/〜〜.cgi を訪問せよ」〜と書かれたら どうでしょうか。 『田中のサイトを訪問すると、ＰＣに 危ないファイルを突っ込まれる』〜 といった類の中傷は　以前から行われていますが、 私としては、あなたのＰＣに【クッキーファイル】を保存する必要はありません。 信用できない方は、C:\windows\Cookiesフォルダを監視しながら閲覧すれば良いでしょう。 ◇【クッキー保存（書き込み）を受け入れる設定】で　私のサイトを訪問しても、あなたのＰＣには　何も保存されないハズです。 　「クッキーに時間制限を設定してるんだから、expires指定でクッキー保存しているハズだ」〜 と言う人もいるでしょう。 　　　※事実提示〜証拠も見せずに、勝手な理屈・想像で中傷する２ｃｈネラーが好みそうな“言い掛かり”↑。 ◆通常、クッキーに日時を制限する場合は、expires指定によって 訪問者のＰＣにクッキーを保存し、有効期間を設定しますが、 　私は　この方法を採用していません。 発行したクッキーの内容を、サーバーに　ファイルとして保存し、 これを　ある時間間隔で初期化しながら、訪問者のブラウザから返信されてくるクッキーと照合しています。 こうすれば、 仮に、　技術のある人が　送信したクッキーを偽造して返信しても、その時間範囲内でしか有効ではありません。 「freeDL.cgiを起動した後の クッキー有効時間＝１〜２時間」と、先ほど説明しましたが、 クッキー送信する時に、【乱数発生〜パスワード的な文字列】を　Ａ・Ｂ（２個）作成し、Ａの方をクッキー送信しています。 この時、 Ａ・Ｂ ２個 を、サーバーに　元本ファイルとして保存します。 そして、 色々なページの訪問者がページを開いた時、 隠しＣＧＩが“時間変わり”を認識した時だけ、サーバーに保存した【クッキー元本ファイル Ａ・Ｂ】をシフト更新しています。 “シフト更新”という意味は、 　　ファイルから Ａを読み込んだ後、、ＡをＢに代入コピーし、 　　Ａについては、新規の【年月日時刻 ＋ 乱数文字列】を代入し、ファイルに上書きし、 　　その直後、Ａ・Ｂ ２個の【クッキー元本ファイル】を上書きしています。 このクッキーは、fr1LoginCheck.cgi が送信しています。 　　（ファイル名は 偽名 ↑） そして、訪問者のブラウザのクッキーを検査する時は、２個の【クッキー元本ファイル】のどちらかに一致する・・を照合しています。 こうすれば、 受信したクッキー内容が、１〜２時間の間は、返信されるクッキーは　２つの元本ファイルのどちらかと一致します。 ２本の元本ファイルを使う理由は、 １本だけと照合すると、クッキー発行〜送信した直後に“時間変わり”となった時に、１分で拒否される人も出てくるからです。 in_Top2.htmの場合について、「４〜５時間」と説明したのは、別の Ａ〜Ｅ ５個の【クッキー元本ファイル】を利用しているからです。 in_Top2.htm を開いた時に【クッキー送信】を行うのは、inTopSureOpen.cgi の役割です。 ※in_Top2.htm を開いている人は、ブラウザで【表示 ⇒ ソース】と操作して下さい。 　いちばん最初に、 　と　記述されていますでしょ。 　背後で動作しながら　１ドットの画像を表示して終了しています。 　inTopSureOpen.cgi は、【クッキー元本ファイルの更新時刻チェック】と【クッキー送信】を行うだけです。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ ●【クッキーの制限・規約】について、 一般のＰＣユーザーに関心のある事を選んで書きます。 ◇クッキーによって　サーバー側からブラウザ側に送信（保存）できる情報には、制限がある。 　　１．ユーザー側に対して クッキーで書き込める内容は、テキスト形式のみ。 　　　　　（つまり、 この Java_Cookie.txt と同じで、 通常の【読むための文字情報】だけ。） 　　２．クッキーをパソコンに書き込める保存先は制限されている。 　　３．決められた書式でのみ、クッキーによって送信（書き込み）できる。 　　４．ユーザーの個人情報などは、サーバー側に送信されない。 　　５．サーバー側は、ユーザー側に対して、サーバー側自身が送信したクッキーしか受信できない。 　　　　つまり、【他のサイトでユーザーが受信したクッキー】を、別のサイト（サーバー）が読み取る事は出来ない。 　　　　　※“サーバー側”とは、つまり私です。　ユーザー側とは、つまりあなたです。 　　　　　※“書き込み”も“書き込み無しの送信”も、 送信データは同じです。 　　　　　　送信側で　【書き込み指定】をするかしないかの違いです（expires指定）。 　　　　　　【書き込み指定】をせずに送信した場合は、ブラウザを終了すると クッキーデータは消去されます。 ◇クッキーfile の中の“データ領域”は、サイズ上限が４ＫＢまで。 ◇同一のドメイン・サーバーについては、クッキー数の上限は ２０個まで。 要するに、 　いま流行の 【スクリプトによって危険なコードを実行させる】〜 というような事は、 クッキーでは無理なのです。 　クッキーで出来る事は限られています。 　映画で出てくる『山・・川』〜 という 合言葉のような処理です。 ※『本家サイトの in_Top2.htm が送信した【暗号クッキー】を、freeDL.cgi が検査する』〜 と書きましたが、 　簡単に言えば、 　あなたが in_Top2.htm を開いた時に、“川”という文字を　あなたのブラウザに送信しています。 　そして、あなたが　freeDL.cgi を開いた時に、 　freeDL.cgi は、 あなたのブラウザに対して　「山」と怒鳴り、あなたのブラウザが 「川」と答えるかどうか、 　処理の先頭部分で　検査しているのです。 　もし　「川」と答えなければ、『in_Top2.htm を開いたという証明書が無いから、帰れ』〜 という処理を行っています。 　そして、 　【暗号】としての機能を持たせるために、その 山 と 川 の文字を 頻繁に変化させています。 【HTTP_REFERER】でも　大体　同様の目的を果たせるのですが、 　訪問者の接続状況によっては、REFERERを取得できなかったり、 　プロキシ接続で訪問するブラウザは【ウソの REFERER】を返したりします。 　それで、　訪問者にとって 設定変更が楽な【クッキーによる検査方法】を採用した訳です。 　仮に、危険なコード内容をクッキーに書き込んで　送信したとしても、 　それを受信したユーザーが、その内容を、それを実行できるアプリケーションに対して、 　意識的に　それを実行できる形で 引き渡してやらない限り、不可能です。 【個人情報の サーバー側への送信】については、 ネット販売で　クッキーが使われていますが、 あれは、ダイアログボックスで　自分の意思で 入力・送信しているのです。 勝手に　サーバー側へ送信されている訳ではありません。 『田中のサイトを訪問すると危険な目に遭う』〜 と、メジャーなサイトで書かれたりしていますが、 Cookie という不可解な名前の Windows機能について　知識の少ないＰＣユーザーの心理に付け込んだものでしょう。 　（馬鹿は　それに乗せられる）