- PR -

ASP.NETでの閲覧者情報

«前のページへ 2|3|4|5|6|7|8|9|10|11|12 次のページへ»

投稿者

投稿内容

蓮華: 常連さん; 会議室デビュー日: 2004/11/06; 投稿数: 25

投稿日時: 2005-07-25 13:26

がるがる氏

本題の件で私は
＞HTTPがTCP/IP上で提供されるとは限らない。
＞ASP.NETはTCP/IPベースで提供されている。
＞TCP/IPはUDPと違い投げっぱなしではない。
という風に書き込みました。
誤解のある書き方をした私が悪いのですが、その後の書き込みなどを見てから
突っ込んで欲しいものです。
2chのように揚げ足をとって遊んでいるというなら別ですが・・・

また、色々な脅威について語られていますが、
踏み台にされないなどは、言うまでも無く注意すべきことでは無いのですか？
色々なアイデアが出てきたなかで、その方法ではこういったセキュリティの穴がある
などの情報はありがたいのですが、現状については既にセキュリティを考えた上で
実装しており、これが今回の問題ではありません。

また、HTTPだのブラウザだのASP.NETだの言っていますが、
最初に書いたとおり、この辺にこだわってはいません。

このＢＢＳに書き込む前、プロジェクトではTCP/IPでどうにかできないか？
という案もでました。
ネットワーク系のコマンドラインなりツールなりでこういった情報が取れないものか？
（以前の書き込みでNETSTATコマンドがどうとか書いたと思います）
それともパケットモニタのような機能を実装し、パケットを解析すれば
できるのではないか？
などの意見が上がりました。

しかし、我々の知識不足からもっと簡単な方法は無いものだろうか？という事で
こちらのＢＢＳに書き込んだ次第です。

正直、このような話の流れにウンザリしています。
私は、当初の質問の事項についての技術的な意見交換を期待していました。
また、最初の方の書き込みでもASP.NETやHTTPでの実装は難しいであろうという事も
書きましたが、以前として出てくる意見は、HTTPの仕様やなぜ無理かという
既にわかりきった情報ばかりです。

皆様の技術やレベルが高い事は認めますが、一定方向からの技術にしか目が行かなく
少し頭が硬くなっているように、私からは見られます。

にしざき: ぬし; 会議室デビュー日: 2003/06/30; 投稿数: 304

投稿日時: 2005-07-25 13:56

だって HTTP では難しいからスマートクライアントにすればって意見は
否定するし、DAIさんが「こだわっている」ように見えるんですが。

cats: 大ベテラン; 会議室デビュー日: 2002/11/29; 投稿数: 221; お住まい・勤務地: 東京

投稿日時: 2005-07-25 14:34

全部読んでないので、外れていたら失礼。

REMOTE_ADDRを見て、指定時間以内だったら、ダウンロードできないようにするというのはダメですか。

コード:

string key = "DL Time " + Request["REMOTE_ADDR"];
object o = Application[key];
DateTime t = o != null ? (DateTime)o : DateTime.MinValue;
TimeSpan ts = DateTime.Now - t;
double d = 10 - ts.TotalSeconds;
if (d > 0)
{
	Label1.Text = d.ToString("F2") + "秒待って下さい";
	return;
}
Response.ContentType = "application/vnd.ms-excel-csv";
Response.AddHeader("Content-Disposition", "attachment; filename=\\"abc.csv\\"");
Response.Write("abc\\n");
Application[key] = DateTime.Now;
Response.End();

がるがる: ぬし; 会議室デビュー日: 2002/04/12; 投稿数: 873

投稿日時: 2005-07-25 14:56

がるです。
少々どころではなく長くなり恐縮ですが

引用:

DAIさんの書き込み (2005-07-25 13:26) より:
本題の件で私は
＞HTTPがTCP/IP上で提供されるとは限らない。
＞ASP.NETはTCP/IPベースで提供されている。
＞TCP/IPはUDPと違い投げっぱなしではない。
という風に書き込みました。
誤解のある書き方をした私が悪いのですが、その後の書き込みなどを見てから
突っ込んで欲しいものです。

さて。どの辺に「奇異さ」を感じられましたかな？
DAI氏の

引用:
HTTPがTCP/IP上で提供されるとは限らない。 ASP.NETはTCP/IPベースで提供されている。 TCP/IPはUDPと違い投げっぱなしではない。ならば、我々が特に意識せず使用しているASP.NETはTCP/IPであり投げっぱなしでは無いという事ではないのでしょうか？私の認識が間違ってるのでしょうか？

という書き込みからの修正がないことからも予測されるとおり、
DAI氏がHTTPというプロトコルをどこまで認識しているかについては
非常に懐疑的であると感じられますが。
まがりなりにも技術者であるのなら(ないにしても、ですが)、
きちんと「根拠」を提示しつつ発言しましょう。
根拠を省略しての発言は、あまりにも軽く、薄く感じられます。

引用:
また、色々な脅威について語られていますが、踏み台にされないなどは、言うまでも無く注意すべきことでは無いのですか？

言わなければ通じない。そんなものです。
また、
・踏み台にされてはいけないと漠然と認識する
・詳細なクラック手段のリストを元に「明瞭に」認識する
では、それこそ天と地ほどの差異があるのもまた事実です。
そうして「自分が知らないことは認識できない」事もまた。
だからこそ「わかりきっているはずの事象」でも「あえて文字
にする」ことで、自分の「欠けている」部分を他人に補って
もらうものなのですが。
厳しく言えば。「言うまでもなく」という言葉を使っている
限りにおいて、その人は「無知の無知」状態であるといえます。

引用:
色々なアイデアが出てきたなかで、その方法ではこういったセキュリティの穴があるなどの情報はありがたいのですが、現状については既にセキュリティを考えた上で実装しており、これが今回の問題ではありません。

はたで見て、とうていセキュリティを考慮しているようには見えませんが。
詳細は過去の記述をご参照ください。

引用:

正直、このような話の流れにウンザリしています。
私は、当初の質問の事項についての技術的な意見交換を期待していました。
また、最初の方の書き込みでもASP.NETやHTTPでの実装は難しいであろうという事も
書きましたが、以前として出てくる意見は、HTTPの仕様やなぜ無理かという
既にわかりきった情報ばかりです。

ほほぉ。「無理である」ことが当初から認識できていたとは
到底思えませんが？
詳細は後述いたしましょう。

引用:
皆様の技術やレベルが高い事は認めますが、一定方向からの技術にしか目が行かなく少し頭が硬くなっているように、私からは見られます。

「技術をろくに知らなくて自分のやりたい事をそのまま押し通したいだけ」
の営業さんがよくいうタイプの発言ですね。
せめても、DAIさんが「相応の技術力を持った」うえで「頭の柔らかい」
発想を提示できるのであればまだしも、なのですが。
本当に「頭が固い」状況であれば、理由など提示せずに頭ごなしに
「駄目だ」っていうものです。
みなさんそうでしたか？
「きちんとした理由を筋道たてて説明した上で」駄目だとは
言われてませんか？

柔軟な発想ととっぴな発想の差異くらいは考えてみたいものです。

ーー
さて。

引用:

また、HTTPだのブラウザだのASP.NETだの言っていますが、
最初に書いたとおり、この辺にこだわってはいません。

このＢＢＳに書き込む前、プロジェクトではTCP/IPでどうにかできないか？
という案もでました。
ネットワーク系のコマンドラインなりツールなりでこういった情報が取れないものか？
（以前の書き込みでNETSTATコマンドがどうとか書いたと思います）
それともパケットモニタのような機能を実装し、パケットを解析すれば
できるのではないか？
などの意見が上がりました。

しかし、我々の知識不足からもっと簡単な方法は無いものだろうか？という事で
こちらのＢＢＳに書き込んだ次第です。

この発言ですが。過去のDAI氏の発言を追いかけていくに、
仮に上記が事実であると仮定してなお「明らかに伝達能力に欠けている」
事がありありと伺えます。
# その時点でSEとしてはマイナスですね。

ちなみに先に少々。

引用:
ネットワーク系のコマンドラインなりツールなりでこういった情報が取れないものか？（以前の書き込みでNETSTATコマンドがどうとか書いたと思います）それともパケットモニタのような機能を実装し、パケットを解析すればできるのではないか？

まぁ「情報は取れます」が(限定されているとはいえ)。
どうやって「ダウンロードを絞る」つもりだったのでしょう？
動的にフィルタリングでもかけますか？
# それこそ「かなり高度な技術」が必要ですが。
# っつかそもそも「ルーティング」をあわせないと意味ないですが。
# 「盗聴」じゃなくて「抑制」が目的である以上は。
# 技術力が一定のところになったら、一度「パケットフィルタリング」
# 系のファイアウォールとか実装するのも面白いものですが。

引用:
それともパケットモニタのような機能を実装し、パケットを解析すればできるのではないか？

どのように？
モニタリングで解決するような要求にはまったく見えませんが？

引用:
しかし、我々の知識不足からもっと簡単な方法は無いものだろうか？という事で

随分と初期に回答がでて、それを突っぱねたのはほかならぬDAI氏だと
思われますが。
回答は「認証機能を付ける」。
私は.NETは得手ではありませんが。人づてに聞く話ではAPIに認証機能が
存在しているようなので、それこそ「容易に」実装が可能なはずですが？
ダウンロードの完/未完についてはまた別途、ですが。

さて、本題。
当初のDAI氏の書き込みに拠れば

引用:

掲題の件ですが、ASP.NETにて今現在どのページに何人の人間が閲覧しているのかを
管理者などが専用のWeb画面にて見たいというニーズが出てきました。

また、資料やサンプルなどWeb上にてダウンロード可能なファイルについて、
正確なダウンロード数をカウントしたい、そして同時にダウンロード出来る数を
負荷分散のために制限したいというニーズもあります。

とあり、この時点では「ASP.NETである」ことは前提条件の１つである
ように見受けられます。
しかる後に

引用:

またダウンロード数制限ですが、この制限というのは全体のダウンロード数の
制限ではありません。
1人が同時にダウンロードできる制限です。
-中略-
この機能についても、ユーザがプライベートで使用しているCGI（Perl）の
レンタルサービスにおいて俗に言われるアップローダーにそういった機能が
付いているそうです。（確認してみました）
私の想像ですが、恐らくそのレンタルサービスが動作しているサーバでの
ネットワーク状況か何かをPerlのCGIが調べて判断してるのだと思っています。

との書き込みから、やはりHTTP上で処理を行うことが前提になっている
ことが伺えます。

引用:
ASP.NETでやるべき事では無いとの意見もありますが、特にASP.NET"だけ"で実現させるつもりは最初からありません。問題はWindowsの機能やサービスなどからの情報をどうやってASP.NETで使うのかだと思っています。

ここ部分で「だけ」に強調がなされていること、またその後に
「どうやってASP.NETで使うか」といった発言が重なっている
ことから、ASP.NETを用いることは欠かせない条件であるか
それに近しいであろうことを予見させます。

引用:
HTTPの特性上、特に問題になる仕様だとは思っていません。解決策が見つからないだけです。また、ブラウザはIE、JavaScriptはONなどの規制はしています。それ以外での動作の保証はしないという事は客側でも同意見であり了承済みです。

この時点において、やはり
・HTTP上で問題なく運用できる使用である
と認識されていること、また
・ブラウザが前提になっている
ことから、最低限HTTPで、また、前述からほぼ確実にASP.NETでの
開発であろう事が推測されます。

引用:
ですから、今問題なのは『ダウンロードが正常に完了した』という情報をどう取得するか？なのです。

この時点において特に注意書きがないことから、たいていの人は、
今までの流れを汲んで「HTTP上で」という文章が暗示的に付随しているで
あろうと予測します。

引用:

というのは、例外が発生したとしてどうやってその情報を受け取るのでしょう？
<a href="○○○.zip">○○○</a>
というHTMLの羅列になります。（JavaだろうとASP.NETだろうと）

これをクリックしてダウンロードのダイアログが出てきて、
キャンセルすると例外が発生。
その例外はどうやって受け取る？

この時点でもHTMLで書かれていることから -以下略-。

引用:
投げっぱなし？ HTTPはTCP/IPなのですから投げっぱなしという事は無いですよね？ ASP.NETで情報は取れないでしょうが、下層では分かるはずです。ならば、下層の情報を何かの方法でASP.NETから取得できないものか。こういった情報が欲しい訳です。

ここでもASP.NET及びHTTPについてのみ言及されていることから -以下略-。

引用:
ですから、何度も書いていますが、無理なら無理でかまわないのです。 HTTP以外の技術で何とかならないか。またHTTPでもある程度の前提条件が伴えば、それなりの精度のものが作れればいいのです。

この時点で初めて「HTTP以外でも」となるわけです。

この流れにおいて

引用:
また、HTTPだのブラウザだのASP.NETだの言っていますが、最初に書いたとおり、この辺にこだわってはいません。

と書かれても、たいていの人は困惑するでしょう。
# 「最初ってどのへん？」とかいう突っ込みもありますが。

また、上述の発言をシンプルに捉えると、冬寂さんの

引用:
新しいプロトコルでも作るつもりなんでしょうか？

という発想に行き着くひとは多いと思うのですが。
私も「まったく同じ」感想を持ちましたし。

その上でなお

引用:
HTTPで無理というならHTTP以外なら何でも良い訳であり、どこかにログが取られていてそういった情報を使うとか TCP/IPでの状況がわかればなんとかなるなら、パケットモニタのような機能を作り、そこから情報を取得するとか、なんでも良い訳です。

ログでどうにかなるとかパケットモニタリングでどうにか
なるとか、このあたり「根本的に思慮が足りない」としか
思えない発言が続いていて、なんかこぉ「半分笑えて半分
あきれて」状態です。
一応念のため技術的解説。
今までの記述を見ている限り、基本的要求は以下の３点です。

1.ある瞬間的時間軸における「閲覧者数」の把握
2.ある瞬間的時間軸における「ダウンロード人数」の制限
3.ある瞬間的時間軸におけるダウンロード機能の「個人をキーにした排他」

１番についてはそもそも「ダウンロードしている」「していた」
(つまりは閲覧している「であろう」）ことしかわからないのですが。
まぁかなりの制限を課すことで、ログやらパケットモニタリング
やらで解決できないでもないです。
(Pageのダウンロードから３分以内なら「閲覧しているとみなす」とか)

で。２番と３番は「TCPパケットに対して直接的な制御」が
必要になる機能です。
したがって、「閲覧したことを表す」ログやら「現在パケットが
流れていることを見ることが出来る」モニタリング程度では
どうにもならんです。

OK？

で。

引用:
新しいプロトコルを作るつもりはありません。また、返答して頂いてる方が、難しく考え過ぎている気がするのは気のせいでしょうか？

気のせいです。あるいは、DAI氏が簡単に考えすぎです。
あるいは、ほかの方々が「なぜそのように考えるのか」を、
もう少し真摯にとらえられてみてはいかがでしょうか？

DAI氏のクライアントさんのお話は「要求としては」非常に
面白いとはおもうんですがね。
もうちょっと違ったアプローチが「なんぼでも」あるように思います。
個人的雑感ですが。

masa: 大ベテラン; 会議室デビュー日: 2005/05/11; 投稿数: 108

投稿日時: 2005-07-25 15:03

こんにちは。

本題から外れる議論を続けることになりDAI様には申し訳ないのですが、
私の中で消化しきれませんので、もう少しだけ続けさせて下さい。

引用:

がるがるさんの書き込み (2005-07-25 12:10) より:
このJittaさんの発言でほぼ「全て」ではあるのですが。
TCP/IPは、受け取り手が「欠けているパケット」を必要に応じて
「サーバ側に再送信を要求するための」手順と手法が確立されています。
これが一般に「UDPと違ってTCPは確実性がある」といわれる所以です。
ちなみに、この機能のためには当然のことながら
・エラーであることを認識できるためのなんらか
・エラーが発生した場合に「再送要求」を依頼するなんらか
が最低限必要となります(実際にはもうちょっと色々と)。

で。HTTPに、とりわけ「HTTPのクライアント側の実装」に、
そういった再送手順が存在しますか？
HTTPの仕様はRFCにきれいにまとまってます(いやあれがきれいか
どうかは主観にも拠るのでしょうが、そこは敬意を表してって
ことで )。

HTTPで規定されているのは
・クライアント側(ブラウザ)からサーバに送られるREQUEST
・サーバがREQUESTに応じてクライアント側に返すRESPONCE
だけです。

「今」知らないことがあるのは当然です。でも、知らないことが
わかったなら、勉強くらいしませんか？

HTTPの下位層にあたるTCPレベルでの通信時の動きとして、一旦接続を確立
したConnectionへServer側がメッセージ送信を試みた際に、既にそのConne
ctionがクライアントによって切断されていた場合、
"Connection reset by peer"の応答メッセージがServer側に返されます。

私がTomcat、JavaServlet、IEでのテストを行った際に検知した例外も
"java.net.SocketException: Connection reset by peer: socket write error"
と、そのままであるため、少なくともIE環境においては
クライアント側キャンセルの挙動を拾えるのではという結論に至ったのです
が、どこか根本的に誤った解釈をしている部分があるのでしょうか？

私自身まだまだ勉強中の身で、自分の中で辻褄のあった場合にのみ掲示板で
発言するよう注意しているのですが、私の誤った解釈が元で議論を混乱させ
る要因の一つとなっているとしたら、その際は皆様に深くお詫びしたいと思
っております。

がるがる: ぬし; 会議室デビュー日: 2002/04/12; 投稿数: 873

投稿日時: 2005-07-25 15:20

がるです。
未だ消化不良との事なので。おいらの発言が大田胃散に
なればよいのですが(笑

引用:
masaさんの書き込み (2005-07-25 15:03) より: HTTPの下位層にあたるTCPレベルでの通信時の動きとして、一旦接続を確立したConnectionへServer側がメッセージ送信を試みた際に、既にそのConne ctionがクライアントによって切断されていた場合、 "Connection reset by peer"の応答メッセージがServer側に返されます。

うい。これについてはそうです。
# 実験はしたことあるです。「面白い実装だなぁ」とか思いました。

引用:

私がTomcat、JavaServlet、IEでのテストを行った際に検知した例外も
"java.net.SocketException: Connection reset by peer: socket write error"
と、そのままであるため、少なくともIE環境においては
クライアント側キャンセルの挙動を拾えるのではという結論に至ったのです
が、どこか根本的に誤った解釈をしている部分があるのでしょうか？

端的に一言で片付けると「仕様と実装の違い」ですね。
ちょいと厳密な話になるのですが。

HTTPの仕様を取り決めているRFC上において、
・パケットの流れが途中で中断したときに何らかのエラーを発生させる
という仕様はないです。
つまり、この時点から「HTTP上の仕様として、クライアント側の
キャンセルを拾える情報が存在しない」ことになります。

ただ、実際に例えば「Windows 2003上で動くTomcatを開発」する
時に、あるいは「TCPではパケット中断が受け取れるんだから、ここは
例外を発生させたほうがより便利だよねぇ」ということで実装を
することは十分にありえますし、この例については「実際に実装された」
パターンであると思われます。
# 仕様とぶつかり合うような内容でなければ、割合によくあります

この場合、
・限定された実装系(今回ならWindows上のTomcat)においてその挙動が起きた
は確かに真であるのですが、それが
・ほかの実装系にちゃんと実装されている
とは限らないですね(仕様にない動作なので)。

つまり、ここが「仕様と実装の違い」です。
# ぶっちゃけ「LinuxでApache」の実装系だと例外おきません(笑

まぁ、これは昔に私も怒られたのですが。
「実装を叩いて確認なんかするな。まずは仕様書をちゃんと確認しろ」
私の場合、リアルに「怒鳴られました」(笑
でも、確かに、特にHTTPなどは「元となる仕様」がきちんと存在
しているので、そちらをまず確認するのは「正しいなぁ」とか
思ったものです。

引用:
私自身まだまだ勉強中の身で、自分の中で辻褄のあった場合にのみ掲示板で発言するよう注意しているのですが、私の誤った解釈が元で議論を混乱させる要因の一つとなっているとしたら、その際は皆様に深くお詫びしたいと思っております。

いへいへ。間違った解釈をみんなで考察したり修正されていったり
する過程「こそが」もっとも重要な勉強だと思うです。
大切なのは「疑問に思うこと」と「間違えること」:-P
で、間違いと疑問が解消されていく過程が「学習」だと、おいらは
思ってるです。

todo: ぬし; 会議室デビュー日: 2003/07/23; 投稿数: 682

投稿日時: 2005-07-25 15:21

では、違った観点から..

引用:

先程も書いたように1プロジェクトで最大1000近くのファイルを落とす場合が
ありますが、基本的にファイルは1つずつ順番に使っていくことになりますので、
1人が仕事をする上で同時に複数のファイルは必要無いのです。

ところが、殆どの人間が朝、出社してくるとダウンロードツールなどを使い、
今日1日必要なファイルを一気にダウンロードしようとします。
この時点でサーバ負荷が高くなり、ダウンまではしませんが・・・という状態です。

ちなみに、このファイルが無いと仕事になりません。
ただし、仕事をする上で必要なのは1ファイルあれば良いので、
1ファイル落とした後、仕事を進め、その作業が終わったら次のファイルを開いて
作業をするという形になります。

「1ファイル落とした後、仕事を進め、その作業が終わったら次のファイルを開いて作業をするという形」

が嫌だから、

「殆どの人間が朝、出社してくるとダウンロードツールなどを使い、今日1日必要なファイルを一気にダウンロードしよう」

とするのでは？

非ユーザーフレンドリーな仕様が、そもそもの問題にみえます。

蓮華: 常連さん; 会議室デビュー日: 2004/11/06; 投稿数: 25

投稿日時: 2005-07-25 16:05

無駄な議論は不毛なので部分的にレスします。
何度も言いますが現状の状態でセキュリティ的に問題は何1つありません。
ここで色々と出てきた実装方法でセキュリティ的に問題がある場合などは歓迎です。

引用:
まぁ「情報は取れます」が(限定されているとはいえ)。どうやって「ダウンロードを絞る」つもりだったのでしょう？動的にフィルタリングでもかけますか？

ですからNETSTATでは、あるホストと通信はしてるんだなという事は分かるけど、
何をダウンロードしてるかなどの情報は取れないと書いたはずです。

引用:
どのように？モニタリングで解決するような要求にはまったく見えませんが？

そうでしょうか？
実際にこれもNETSTATと同じで案だけで詳しくは別の人間が頑張っていますが、
パケットのヘッダで送受信のIPやポートが分かります。
また、なんのデータを送受信しているのかも分かります。
更に、現状の通信状況がどうなのかも分かります。
ならば、サーバ側でサービスなどでダウンロード途中のデータの情報だけを
保持しておいて、ASP.NETからこのサービスへ状況を問い合わせ、
ダウンロードの状況を知ることは出来ないだろうか？という事です。

«前のページへ 2|3|4|5|6|7|8|9|10|11|12 次のページへ»

＠IT SpecialPR

ASP.NETでの閲覧者情報

スキルアップ／キャリアアップ（JOB@IT）