 |
|
||||
| ＦＡＱ・３ |
 |
| カレッヂ |
- いたずらに困っています
- リロードしたら２重投稿されてしまった
- ネスケとＩＥの思わぬ違い
- クッキーについての問題
- アクセスルート調査
- ＭＡＣで転送すると化ける？
- HPUXサーバにflyをインストールする方法
- ショッピングバスケットで商品が選択できない？(クッキーの処理)
- 半角カナはご法度！
- アクセス制限設定時に注意すること
- 掲示板での改行の扱いについて
- アクセス制限でサーバエラーになる場合
- リモートホスト名が出ない？
- 簡易ＢＢＳなどでマスターキー(管理用パスワード)を忘れてしまった
- ファイルアップロード機能を持つシステムをＮＴサーバで使う
- ＩＥ５の問題点(改行系)
いたずらに困っています
これは古今東西、一向に無くならないものです。 犯罪がこの世から無くなることはないでしょうが、ただ悩んでいても解決にはなりません。 いたずらといっても多種多様にあります。 プログラマとしての私にできることは、技術的な攻撃に対してプログラムで措置することです。 ある程度の手口に対してはそれなりの対応をしていますが、私の想像を超えた技術でこれからも出てくるでしょう。 厄介なのはこのような頭を使ったものではなく、誰でもしようと思えばできる通常投稿です。 書かれる内容が悪意に満ちたもの、悪気はないのに読者に不快感を与えてしまったもの、 誉殺しなど、普通に投稿される内容をプログラムで措置することは非常に困難です。 私の期待を超える数で簡易ＢＢＳが普及しているようですので、 必然的に簡易ＢＢＳに対する攻撃が多いとレポートされますが、掲示板そのものに対する攻撃よりも、 その掲示板の存在に対する攻撃が殆どです。不適切な投稿かどうかは、ヒトが内容を読んで判断しなければわかりません。 こまめに管理できるように、例えば簡易ＢＢＳには投稿時に管理者にＥメールする機能などがあります。 さらに、簡易ＢＢＳv8.8s(98/3/8現在の最新バージョン)では、管理者が内容を確認してから公開するタイプのものも用意しています。 このような対策をすると、折角リアルタイムに書き込める掲示板が、管理者の確認を待たないと掲示されないなど、 掲示板の利点が失われていきます。 このように段々規制が生まれるのは仕方ないのかもしれません。 まずどのようなタイプ(手口)かを確認してみてください。インターネットという自由なネットワークにアクセスすることはとても便利で楽しい面があります。 と同時に様々なリスクを伴います。電話番号を公開すれば悪戯電話の可能性が出るのと同じように、 Ｅメールを公開すれば同様のことが起きる可能性もあります。沢山のひとからメールが欲しい場合、 公開すれば手軽にメールがもらえるようになるでしょうが、反面そのようなリスクを伴うことを忘れてはいけません。 掲示板やチャットなどその他の手段でも同様です。インターネット等の外部のネットワークと接続しているだけで、 会社の秘密情報が盗用された事例もあり、ある会社では社外とは接続させていないところもあるようです。 接続しなければそれだけ不便になるわけですが、それを承知で対策をしているわけです。 同様に、個人のパソコンにモデムを付けなければ、外部から侵入されることはないでしょう。 しかし、運転手が事故が恐くて車に乗らないのでは何もできません。 まず怖さを知ることが利便さを追求する第一歩ではないかと考えます。 その価値観は人それぞれ違いますから、どこまでのリスクを考えてどこまで利用するかはあなた次第ですが、 いたちごっこであるにせよ、私の場合は私のできる範囲でできるだけのことをしていきたいと思っていますので、 みなさんのご協力をおねがいします。
リロードしたら２重投稿されてしまった
リロード(Reload)とは、「その画面で直前に行った処理を再度実行する」ということです。 単にそのページを閲覧しただけであれば、リロードすればその画面をもう一度読み出すだけですが、 掲示板などで投稿した直後の画面でリロードするということは、今投稿した処理を再度実行するという意味になり、 「送信フォームから送り直しますか？」と聞いてくるのです。 画面だけを最新のものにしたければ、ＵＲＬ欄にカーソルを持っていってリターンし、 それでキャッシュを読むようであれば、そこでリロードすればいいのです。ネスケとＩＥの思わぬ違い
ネスケとＩＥ、ここではネスケ3.01、ＩＥ4.0で確認したことをお話します。 ネスケでは動作するのにＩＥでは駄目ということがあります。 フォントの違いなどの見た目の問題ではなく、ＣＧＩ処理上の問題です。 設計していて次のを技術メモとして記載します。●ネスケとＩＥの動作の違いにおいて、記入者の意志に関係なく枠内で見た目改行されてしまうＩＥを ネスケと同じようにする（処理上もネスケの方が正しく処理されている）には、 <textarea>内に wrap=off を設定してください。 見た目改行とは、実際にはその位置に改行が記録されて送信されるのではないのに、 textarea枠内で折り返してしまうことを指します。 記入者の意志に関係なくそうなってしまうのは、 例えば表などを書いていてもっと横に長くしたいのに折り返されるのはおかしいということで、 ネスケと同じように、記入者の意志に沿って横スクロールするようにするということです。 wrap=offを設定しないとそうならないことから、改行されていると思って投稿したら、 横に長い文章になってしまったという経験はありませんか？ 思わぬＩＥの弊害でした。 なお、ＨＴＭＬタグのことですので、旧バージョンのブラウザで対応されて いないものもあると思います。既に広く普及しているＩＥ４で動作確認しました。
wrap=soft 画面上のみ自動改行(デフォルト) wrap=hard 画面上の改行と同じようにフォームで送られるデータも改行される wrap=off 自動的な改行はされない(横スクロールしていく)
●アクセス制限しているページでＳＳＩで貼り付けられた <!--#exec cmd="echo $REMOTE_USER"--> をソースでみると最後に改行が付いていることがわかります。 これは以前から知っていました。 しかしこの改行は ＩＥでは\r\nでネスケでは\nになっていることがわかりました。 入力バッファを調査してみたところ、
IE4.0 id=rescue%0D%0A ネスケ3.01 id=rescue%0A
従って、この変数に関して、\nと\rを消去する処理を入れなければ、純粋にＩＤだけを取り出すことができません。 検索などにこのＩＤを使う場合、これらのコードがあるだけで抽出できなくなります。 目には見えないので分かりにくいと思います。
●ネスケではフォームからデータが送信されるのに、同じ画面でＩＥではデータが何も送信されない事例がありました。 ブラウザからのデータの出力が取得できないものなので、プログラムのミスではないのでなかなか原因がわかりませんでした。 この場合、インプット行をテーブルの中に置いて整列させています。 これはＨＴＭＬの書き方の問題で、当初は
print "<table><form method=post action=\"foo.cgi\"><tr>\n";
にしてありました。ネスケでは問題ありません。 通常、<form>や</form>には改行も含まれてしまうので、 <td></td>などの中に入れると表が見にくくなるので入れません。 ＩＥの場合、これをテーブルタグの意味のなさない場所、 この場合、<table>と<tr>の間に入れてしまうと、正しく認識されないようです。 しかしSUBMITボタンは出ますので、ということは<form>は認識されているはずですので、 ＩＥのバグではないかと思います。とりあえず、テーブル制御の外に置くことで解決できます。
私独断と偏見による所見を申しますと、 ネスケはファジーなブラウザで、人間がちょっとしたＨＴＭＬ記述ミスをしても、 ある程度柔軟に表示してくれたり処理してくれますが、 ＩＥは文法通りにきちんとやらないと機械的に判断されてしまうブラウザのような感じがします。 それで私はネスケ、それもｖ３程度のものが好きなのです。 機能豊富になって表現の幅が膨らむのはいいですが、普及しないことにはどうしようもありません。 また、ＩＥはＷＩＮＤＯＷＳに添付されているためか、ＩＥの利用者がネスケを超えているようです。 それでＩＥによる問題がクローズアップされてきたのでしょう。
クッキーについての問題
クッキーは共通規格というものはなく、ブラウザやバージョンに左右されたり、 対応されないサーバもあるなど、使えない場合もありますのでご注意ください。 今後どうなるかはわかりませんが、 特に仕様上、ピリオドが２つ以下のドメイン(例 http://foo.bar/ とか http://www.foo.bar/)内では動作しないとか、 古いネスケではpathを設定しておかないと動作しないともいわれています。H.M.Fox.Mulder氏からレポートをいただきましたので、 参考までにご紹介します。ただ、マイクロソフト社がこの内容に関して公式にテストを行った上での話ではないことを 承知した上で参考程度にしてください。
-----
■ テストの概要
クッキー情報をセットするページ、クッキー情報を読み出すページを
それぞれ用意し、各ブラウザを使用して情報がページに正確に反映さ
れるかどうかをテストします。
■ MS InternetExplorer for Windows95
確認： MS InternetExplorer3.01 for Windows95
MS InternetExplorer3.02 for Windows95
MS InternetExplorer4.01 for Windows95
Windows95版のInternetExplorerでは、v3.02のみある条件下において
クッキー情報が正確に反映できないことがわかりました。
v3.02は、v3.0/v3.01のセキュリティやバグを修正したものですが、
マイクロソフト社のプレスリリースにはブラウザの設計を見直し
再構築がなされているとありますので、基本性能は同じものの、
v3.0/v3.01とは別のものととらえるのが正しいかと思います。
v3.02の現象は、ブラウザを再起動した場合にみられるようです。
ここでいう再起動は、クッキー情報が保存されているブラウザが、
アクセスを終えて終了・・次回アクセス時にブラウザを起動
・・というように、一旦ブラウザが終了されてから次回起動される
ような状態のことをいっています。
ブラウザを再起動し、クッキー情報の読み出しページへとアクセス
しても、$ENV{'HTTP_COOKIE'}自体の値が返されません。
結果、情報が反映されなくなります。しかしながら、情報が反映
されていないそのページを再読み込みすると、その時点で情報が
ロードされ、情報が反映されるという現象が発生します。
マイクロソフト社から提供されている2000年問題への対応モジュール
では、クッキーに関する2000年問題が解消されているということで、
若干サーバーに対してのクッキーの動作が変更されたかとは思うの
ですが、この情報が反映されない現象はやはり発生します。
■ MS InternetExplorer for Macintosh
確認： MS InternetExplorer3.01 for Macintosh
MS InternetExplorer4.0 for Macintosh
Macintosh版のInternetExplorerでは、v3.01でクッキー情報が
正確に反映できない場合があるようです。
v3.01の場合は、クッキー情報の保存に問題があるようです。
今回テストを行った際、$ENV{'HTTP_COOKIE'}に同一のテスト
プログラムを使用して同一のクッキー情報をセットしているにも
関わらず、同じキーが二重生成されるという現象を確認しました。
これが直接起因しているのかどうかについては、手元に環境が
ありませんので確認できませんでした。
-----
アクセスルート調査
Ｗｉｎｄｏｗｓ９５で確認したことですが、インターネットに接続した状態で ＭＳ−ＤＯＳプロンプトを起動します。そして、
A:WINDOWS>tracert www.rescue.ne.jp
と入力すると、あなたの接続ポイントからwww.rescue.ne.jpがあるサーバまでの アクセスルートが表示されます。各接続間の質にも寄りますが、 この段階が少ない方がよりアクセスが快適になると思います。 tracert www.rescue.ne.jp でも試してみてください。
ＭＡＣで転送すると化ける？
FETCHを使っている場合、「ISOトランスファ」という設定のチェックを外さないと、 文字が化けてしまいますので注意してください。 （参考になるページ）HP/UXサーバにflyをインストールする方法
ビッグローブのwww2sやwww2uなどのHP-UXサーバにflyをインストールする方法です。 ご自身のサーバが何なのかを調べるには次のＣＧＩを実行します。(表示されない場合もあります)
#!/usr/local/bin/perl print "Content-type: text/html\n\n"; print "OS=", `uname -a`, "\n"; exit;一時公開を中止しておりましたが、要望が多く、注意書きをよく読んでいただくことを条件に公開します。 ビッグローブのHP-UXサーバにflyをインストールする方法
ショッピングバスケットで商品が選択できない？(クッキーの処理)
断っておきますが、これが原因だと思われるということです。 代行設置で次にお話するサーバへの施工で、どうしても商品がバスケットに入らないので調査したものです。 プロバイダ側で、サーバが？発行するクッキーを停止したら正常に動作すれば、それが原因であると確定できるでしょう。まずこの原因を確認するために、クッキーが来たら食べる前に食べるかどうか確認するようにブラウザの設定を変えてください。 ネットスケープなら、オプション-ネットワーク設定-プロトコルで、見る前に警告を出すようにします。 さて、そうしたら設置したシステムにアクセスしてみてください。商品選択するＨＴＭＬフォームのページです。 ＨＴＭＬにアクセスしているだけなのにクッキーが来ましたか？ もしサーバが何らかのクッキーを発行している場合はこのシステムは正常に動作しません。 このシステムは、クッキーを発行した後に Location: でバスケット内容表示のＣＧＩへアクセスしますが、 その間にサーバのクッキーが割り込んでしまって、このシステムで発行したクッキーが無視されてしまうようです。 このシステムに限らず、同様の仕組みでクッキーを利用しているスクリプトは、残念ながらそのサーバ上では正常に動作しません。
たまにこのようなサーバがありますが、ブラウザを立ちあげてから最初にそのサーバ上のどこかにアクセスしたときに発行されます。 一度食べてしまえばいいのですが、上記の様にブラウザ設定して、 把握していないクッキーを不用意に食べないようにしている方もいらっしゃるでしょう。 その場合、そのクッキーを食べない限り、商品選択の為のクッキーを食べることができません。 食べない場合、何のファイルにアクセスしても食べるまで毎回もクッキーが発行されます。 食べる＝ブラウザにクッキーとして保存することです。 プロバイダの方でそのクッキーを記録して何かしているのでしょうか？ 例えば、その情報は、その人がどのページをどの順番にアクセスしたかを、個人毎に把握できてしまうのです。 プライバシーの問題もあるので、アクセスする側としては、そのサーバ上のすべてのファイルにアクセスしたくなくなるかもしれません。 もしプロバイダ側で意味なく単に発行しているだけであれば、その設定を解除して、クッキーを発行しないように要望してみてはいかがでしょうか？ このシステムを使う使わない使えないに関わらず・・・
半角カナはご法度！
インターネットは日本だけのものではありません。 国籍のない自由なネットワークですが、言語コードも何らかの統制がなければなりません。 現在のシステムでは半角カナをネットワーク上で用いることはトラブルの原因になりますので、 ＷＷＷでも電子メールでも使わないように周知してください。 たとえば、電子掲示板で半角カナを入力すると化けることもありますし、 ファイルアップローダでファイル名（パス名も含む）に半角カナがあるとエラーの原因になります。アクセス制限設定時に注意すること
私が私の利用しているサーバで実験等したときには何ら問題がなかったのですが、 <limit>で指定する項目の「postやgetやput」を小文字で書くとエラーになる場合があるようです。 実際のマニュアルをみてみると、 （ＤＢＭ認証はこちらです。） 確かにその部分は大文字になっていました。私もいままで気が付きませんでしたが、 いずれにしても基本通りに設定しておくことがいいでしょう。 なお、当サイトで公開しているこれ関係の設定は小文字になっている場合があります。 バージョンアップ時などに随時変更していきますが、その点ご了承ください。
<limit POST GET PUT> require valid-user </limit>
また、AuthName設定時には日本語では文字化けしてしまう場合がありますので、 できるだけ英文で設定するといいでしょう。それに、設定文字列に半角スペースがある場合は ""で囲まないとエラーになる場合があるようですが、
AuthName パスワード入力画面に表示される文字列 AuthName "パスワード入力画面に 表示される文字列"
マニュアルのサンプルでは、
AuthName restrict posting AuthType Basic AuthUserFile /usr/local/etc/httpd/users
のように、""で囲まれていません。 この辺は、これらの知識を持つことで、実際に試行錯誤して柔軟に設定することが必要でしょう。
掲示板での改行の扱いについて
ブラウザで表示されるテキストは、ＨＴＭＬまたはプレーンとして認識され表示することができます。 掲示板などはＨＴＭＬとして出力していますので、文章はＨＴＭＬとして認識されて表示されます。 ＨＴＭＬを書いたことがある方は分かると思いますが、ＨＴＭＬ文法では改行は認識されません。 改行したいところに<BR>などの改行を指示するタグを挿入します。 半角スペースも、特に全角文字と混じって使うと、スペースをいくつも書いてもそのまま表示されません。 たとえば行頭に半角スペースをいくつか書いた後に文字を書いても、その通りに表示されません。 そのまんま表示するには<PRE>内に書かなければなりません。これらのことでわかるように、一般的な感覚とＨＴＭＬはちょっと食い違いが出ます。 掲示板等でも同様です。たとえば、図や表を文字で表現しても、書いたとおりに表示する処理、 すなわち<PRE>タグで表示されるようにされていないとずれてしまいます。 そのかわり、通常の文章でそのように表示すると、もし適当な個所で改行していない場合は、 横に長くスクロールするようになってしまいます。ＩＥでは、テキストボックス内に書いたときに、 枠を超えると自動的に見た目改行されてしまいますが、実際には改行コードは記録されていません。 ですから、書いている本人はあたかも改行されているように錯覚してしまい、 そのために書いたとおりに表示する処理の場合に横スクロールしてしまうことになります。 ネットスケープでは記入した通りにテキストボックス内でもちゃんと横スクロールされますから、 そういう誤解がありません。これらはブラウザの仕様なので仕方ありません。 そういう意味では、ネスケの方が忠実に再現していることになります。 さらに不都合なことに、ＩＥでは<PRE>タグで表示された内容は通常よりも小さなフォントで表示されてしまいます。 テキストボックス内の見た目改行や<PRE>タグで小さなフォント等、 私が個人的にあまり好きなブラウザでないことの所以です。
これらのことから、記録時に「何もしない」「改行のみ付加する<BR>」「書いた通りにする<PRE>」 を選択するようにすれば、記録したい方が記録する内容によって選択することができます。 しかし、これらを理解していないと、なんで？と思われてしまいます。大多数の方はそうでしょう。 簡易ＢＢＳなどの簡単なものでは、面倒なことはしないように簡素化するようにしています。 ただ、これらをいままで統一した表現で表示していなかったために、 一部のヴァージョンでは改行をするしないの処理を、 <BR>と<PRE>の明確な区別をしないでどちらかを使っていたことがあるので、 昔から使っていてバージョンアップしていた方には戸惑いがあるかもしれません。
「書いた通りに表示する」を選択している場合は<PRE>を使うようにしていきますので、 当然それを選択しない場合は改行や連続した半角スペースは無視されるように表示されます。
アクセス制限でサーバエラーになる場合
パスワードによるアクセス制限などの.htaccessの設定で、 ""で囲むとか大文字で記述することなどを確認してみてください。 サーバによってはそうしないとエラーになる場合があるようです。
AuthUserFile /path/to/.password AuthGroupFile /dev/null AuthName "ByPassword" AuthType Basic <Limit POST GET PUT> require valid-user </Limit> <Files .htaccess> order deny,allow deny from all </Files>
リモートホスト名が出ない？
アクセス解析や掲示板などにおいて、 サーバ側から提供される環境変数でホスト名やＩＰアドレスを表示や記録していますが、 全く表示されないとか、ＩＰアドレスしか表示されない場合、 サーバ側がそう設定している場合が殆どであり、仕方ありません。 サーバを少しでも軽くするためにその機能を停止されているプロバイダも少なくありません。簡易ＢＢＳなどでマスターキー(管理用パスワード)を忘れてしまった
例えば簡易ＢＢＳでは、データファイルの１行目に、それが暗号化されて記録されています。 もし忘れてしまったら、そのデータファイルをバックアップしてから、サーバ上のデータファイルを空にして、最初のパスワードの設定画面にします。 そこでパスワードを設定すると、データファイルに１行記録されますので、 その１行を、バックアップしたファイルの１行と入れかえて設置すれば、 パスワードを書きかえることができます。なお、データファイルを直接編集するわけですから、 改行コードについて十分理解してから行わないと、 ファイルが壊れることもありますのでご注意ください。 とりあえず安心なバックアップとして、バイナリモードで取り出して一切編集しないファイルを別に保存しておくと、 万が一の場合にそれをバイナリで設置すれば、少なくともその時点まで戻すことができます。ファイルアップロード機能を持つシステムをＮＴサーバで使う
ＵＮＩＸやＰｌａｎ９以外で「テキストモードとバイナリモードを区別するシステム」では、 ファイルアップローダや電子日記帳やフォームメールや簡易ＢＢＳの一部のバージョンなどの、 ファイルアップロード機能があるプログラムにおいて、正常に画像が送れないという場合があります。 当サイトのプログラムはＵＮＩＸ用ですので、ご自身で移植などの対応をしていただくことになりますが、 ＮＴサーバに電子日記帳を設置し、画像アップロードを正常に動作させる方法をレポートいただきましたので、 参考例としてご紹介します。
if (!open(UU,"> $image_dir$in{'filename'}")) { &error('エラー','画像が記録できません.'); }
binmode(UU);
print UU $in{'file'};
close(UU);
binmode(UU); をこの位置に追加してください。
Thanks to http://www.yecc.gr.jp/.
ＩＥ５の問題点(改行系)
<form>や</form>はそれ自体に改行させる力があることから、テーブルタグ内で表組がいびつになるのを防ぐために、 <th></th>や<td></td>内には入れないようにしています。 １つのフォームであれば、テーブルタグの外に置けばいいのですが、 同じテーブル内に複数の独立したフォームを置きたい場合は、入れなければなりません。 ＩＥ５ではさらに、<input type=hidden name=foo>のような、画面には表示されないHIDDEN属性のタグが改行を発生させてしまうようです。 表組構成に関係のない場所に置くようにしていましたが、 ＩＥ５ではそれが影響して、テーブルの外にその分の改行が現れて、意図しない場所に行が空いてしまうことがあるようです。↓これだと表組はきれいに表示されるが、表の上に２行分程度の間が空いてしまう。 <table> <tr> <form> <th>あああ</th> <input type=hidden name=foo> <td>あああ</td> </form> </tr> </table>
当サイトのプログラムでそれらしき現象があればご連絡ください。 あまりにも沢山あるので、チェックしきれないために、レポートを頂いて調査し、 対応したいと思います。
|