0

Internet Explorer に基づく自動化された WebBrowser コントロールを使用してログインする、認証が必要な Web サイト内にある URL からファイルを自動的にダウンロードするとします。しかし、そこにいてファイルへのリンクを取得したら、そこに移動してIE6経由で直接ダウンロードしようとすると、「このファイルを開くか保存しますか」というモーダルダイアログが表示されます。そして、C# WebClient クラスを使用してダウンロードしようとしてもうまくいきませんでした。ダウンロードされたのは、意味のない短い JavaScript だけでした。実際、好奇心から、添付ファイルをダウンロードしようとして Gmail Web サイト内の WebClient メソッドをテストしましたが、どちらも機能しませんでした (Gmail から POP3 インターフェースを介してそれらを取得できることはわかっていますが、これは単なる実験でした)。

さて、これはすべての根底にあるメカニズムについて疑問に思います. まず、WebClient を間違った方法で使用している可能性がありますか? または、そのような状況でファイルをダウンロードするための他の標準 C# クラスがあるのでしょうか?

そうでない場合、アプリがブラウザの動作を偽装して、実際には同じプロセスの別の部分からのものであっても、ファイルの要求がブラウザからのものであるとサーバーが考えるようにすることは可能ですか? WebClient ができない間にファイルをダウンロードできるようにする、この状況でブラウザは正確に何をしているのでしょうか?

4

2 に答える 2

2

2 つのネットワーク プログラムの動作の違いを理解したい場合は、ネットワーク トラフィックを調べる必要があります。Fiddlerなどを使用して、各プログラムが何を行っているかを確認し、2 つを比較します。

于 2010-07-18T03:23:21.220 に答える
1

これは通常、ブラウザが送信する Cookie やその他の HTTP リクエスト ヘッダーに関係していました。Web サーバーは、まったく同じヘッダーを送信する限り、人間が操作する Web ブラウザーやコード制御の「Web クライアント」を区別できません。

人間主導の「セッション」認証 (ユーザー名/パスワードの入力) では、通常、いくつかの Cookie がサーバーからブラウザーに送信され、ユーザーは「ログオン」し続けます。これは、ブラウザーが後続の要求を行うときにそれらの Cookie をサーバーに送り返し続けるためです。 .

そのため、Web クライアントが資格情報を正しく送信 (投稿?) し、必要に応じて Cookie (および/または "referrer"/"user-agent" ヘッダー) を保存および再送信し続けることができる場合、違いはありません (最後は単なるリクエストであり、HTT-Protocol のレスポンス チェーンです)。

ただし、使用している特定の「コントロール」には、それ (または API) がマルウェアによって使用されるのを防ぐためのセーフガードがある場合があります。「プログラムがあなたに代わって電子メールを送信しようとしています。これを許可してもよろしいですか?」MS Outlook での 5 秒の遅延がその例です。したがって、使用している特定の API にこの種のプロンプト/予防策がある場合、完全に黙って物事を処理できない可能性があります。

于 2010-07-18T02:40:01.270 に答える