トップ回答者
運用環境に配置したReoportViewer付きのWebフォーム、開こうとするとインターネットへ出ようとする?!

質問
-
ASP.NET4.6/WindowsServer2016のIIS10.0のWebサーバ
現在、WindowsServer2008R2上で運用中のASP.NET4.0のサイトを、ASP.NET4.6として運用していくための移行作業中です。
皆様のご支援もあって、なんとか後継サーバに各ページを移行し、動作確認に入っているところですが、ReportViewer付きのWebフォームを開こうとすると、インターネットへ出ようするケースに遭遇しています。
今日夕刻まで後継Webサーバ(WindowsServer2016)のIEで動作確認していた際は、そのような事象は一切確認されませんでした。
Windows7のクライアント端末、もしくはWindows10のクライアント端末のIEから 当該Webフォームを開こうとすると、きまってインターネットへ出ようとします(ProxyServer経由)。以下の画面はWindows7端末で検証しているところです。
プロキシサーバは認証方式であるため、インターネットへのアクセスを拒否するか許可するかダイアログで選択することができますが、どちらを応えようと 特段事後に表示される当該Webフォームの変化は見受けられません(現在のところ、どの環境で検証しようと真っ白の表示。HEIGHTを100%としているがためのことで後ほど要調整と認識、Excel・PDF・Wordのダウンロードは正常)。
自分なりに調べて、Web.config ファイルのプロキシ設定の構成を参考に以下の記述を 当該WebサイトのWeb.configに追記していますが 変化はありません。Webサーバ実機のブラウザで確認する以外はインターネット(ProxyServer)へアクセスしようとします。
<system.net> <defaultProxy enabled="false" /> </system.net>
【質問】
どうすればクライアント端末で 当該Webフォームを開こうとした際に インターネット・ProxyServerへアクセスしようとしなくなるのでしょうか?Webサーバとクライアント端末で、IEの設定:インターネットオプションが違っていることが故のことなのでしょうか? ご見解よろしくお願いします。
回答
-
> どうすればクライアント端末で 当該Webフォームを開こうとした際に インターネット・ProxyServerへアクセスしようとしなくなるのでしょうか?
ここに書いてある情報以外は何も知り得ない第三者に聞いても答えられないと思いますけど。(少なくともエスパーでは無い自分には分かりません)
質問する前に質問者さんの方でやるべきことがあります:
(1) ネットワーク管理者に聞くなどして、画像にあるダイアログが表示される条件が何なのか明確にする。
(2) 問題のページからどういう要求がサーバーに出るのか、その中で上の条件に引っかかるものはどれかを調べる。Fiddler を使うのがお勧めです。
それで自己解決できるかもしれません。- 回答としてマーク saya24 2019年10月25日 12:54
-
SuferOnWwwさん 仰られるように自己解決できたと思います。
一先ずブラウザの開発ツールでどんなやりとりをしているのだろう、と気になりまして確認してみると、見慣れないURLが見当りました。
早速このURLについて調べたところ、次の二つの記事を発見しました。 記事その1 記事その2
レポートビューアのEnableTelemetry プロパティを無効化すると、無事インターネットのアクセスはなくなりました。お騒がせしました。
<rsweb:ReportViewer ID="ReportViewer1" runat="server" EnableTelemetry="false"> </rsweb:ReportViewer>
Web.configに追記した<defaultProxy enabled="false" />は 関係ないようなので 消しました....
- 回答としてマーク saya24 2019年10月25日 13:53
すべての返信
-
> どうすればクライアント端末で 当該Webフォームを開こうとした際に インターネット・ProxyServerへアクセスしようとしなくなるのでしょうか?
ここに書いてある情報以外は何も知り得ない第三者に聞いても答えられないと思いますけど。(少なくともエスパーでは無い自分には分かりません)
質問する前に質問者さんの方でやるべきことがあります:
(1) ネットワーク管理者に聞くなどして、画像にあるダイアログが表示される条件が何なのか明確にする。
(2) 問題のページからどういう要求がサーバーに出るのか、その中で上の条件に引っかかるものはどれかを調べる。Fiddler を使うのがお勧めです。
それで自己解決できるかもしれません。- 回答としてマーク saya24 2019年10月25日 12:54
-
SuferOnWwwさん 仰られるように自己解決できたと思います。
一先ずブラウザの開発ツールでどんなやりとりをしているのだろう、と気になりまして確認してみると、見慣れないURLが見当りました。
早速このURLについて調べたところ、次の二つの記事を発見しました。 記事その1 記事その2
レポートビューアのEnableTelemetry プロパティを無効化すると、無事インターネットのアクセスはなくなりました。お騒がせしました。
<rsweb:ReportViewer ID="ReportViewer1" runat="server" EnableTelemetry="false"> </rsweb:ReportViewer>
Web.configに追記した<defaultProxy enabled="false" />は 関係ないようなので 消しました....
- 回答としてマーク saya24 2019年10月25日 13:53
-
仰られるまでその点に気が付きませんでした。確かに上記で言及したWindows10のクライアントとは端末的にいえば同じ端末なのです。
当該端末でVisualStudio2017でデバッグ実行していた際は IISExpress64での動作確認になっていた筈で、これが関係しているかも知れません。詳細を確認してみます。
こちらでの動作確認後、次にサーバ実機のブラウザで動作確認に入りましたが、この場面でも インターネットへ出ようとする動作はありませんでした。(これも実は謎、IEの設定由来なのか??)
サーバ実機での動作確認を終えて、再びVisualStudio2017が入ったWindows10で動作確認を行いました。一般的なクライアントの想定で普通にブラウザからのアクセスを行い、インターネットに出ようとする事象を確認しました(デバッグ実行ではない)。別のWindows7の端末でも同じようにブラウザから検証を行い、同じ事象を確認しました。
動作のさせ方は違うものの、同じプログラムのWebページを 同じ端末の、同じ(筈の)ブラウザで開いて挙動が違った理由、調べてみます。突き止められるか正直自信がありません………。
- 編集済み saya24 2019年10月22日 22:16 文字の大きさ統一
-
質問者さんのレスにある開発者ツールの画像で、反転表示させている http://az416426.vo.msecnd.net/scripts/a/ai.0.js への要求が HTTP 407 Proxy Authentication Required エラーとなってますね。
たぶん質問者さんの使っているネットワークでは、インターネットのサイトにアクセスするときはプロキシサーバーを経由するように設定されていると思います。
そして、その時なぜかプロキシサーバーが認証を要求し、それが一番上の質問の認証ダイアログが出た原因に間違いなさそうです。
ReportViewer を EnableTelemetry="false" と設定すると http://az416426.vo.msecnd.net/scripts/a/ai.0.js への要求は出なくなるはずですが(確認ください)、その結果認証ダイアログが出なくなったということだと思います
同じクライアントの同じ IE が同じ http://az416426.vo.msecnd.net/scripts/a/ai.0.js への要求を出しているのに、ケースによって認証ダイアログが出たり出なかったりするのが解せないですね。
IIS Express の影響を疑っておられるようですが、IE から http://az416426.vo.msecnd.net/scripts/a/ai.0.js に要求が出るのは IIS Express でも同じです。(私のレスの画像で反転表示させている行の通り)
質問者さんが言われるように、
> 動作のさせ方は違うものの、同じプログラムのWebページを 同じ端末の、同じ(筈の)ブラウザで開いて挙動が違った
・・・というところが根本的な問題と思います。是非、ネットワーク管理者に聞くなどして調べて、結果を書いていただければと思います。 -
引き続きの報告となります。
初期設定のままのReportViewerを含むWebフォームを、運用環境WindowsServer2016のブラウザで 実行した際に ProxyServerの認証画面が現われなかった理由、周囲に確認致しました。
「IEの設定が一般クライアントのようになされていないから:ProxyServerなど設定していない」という回答を得ました。これについて当方 特段固執することなく すぐ納得しました。
引き続いて、私の開発端末Windows10で
①VisualStudioでのデバッグ実行(IISExpress64)では ProxyServerの認証が現われなかった
②運用環境サイトに当該端末からブラウザアクセスした際は ProxyServerの認証が現れた
という摩訶不思議の事象ついて、再確認することにしました。(この点のほうが疑問を抱いていた)
早速デバッグ実行時もインターネットへのアクセスがなされているか確認しようと、ブラウザの開発ツールを立ち上げて観察しました。====>すると重大なことに気が付きました。「先に提示したURLへアクセスしようとProxyServerへ認証しにいっている & 無事通過している」
--->これはおかしいと思いWindows資格情報を早速確認。...案の定、当該ProxyServerの認証情報が登録されてしまっていました。
--->こちらを削除した上、デバッグ実行を再確認...すると①さえも必ずProxyServerの認証が現われることを確認致しました。
①と②の間で、ProxyServerの資格情報が登録されていた・されていないの違いあったことが、混乱の要因と当方断定付けました。察するにその状況を作り出した背景は、VisualStudioでNuGetパッケージマネージャを利用する際、ProxyServerの認証が現われると私が決まって、入力の認証情報を保存していることにある、と捉えています。(参照追加をスムースにするため)
多分この後のデバッグ実行では ProxyServerの認証ダイアログは現われなかったことは確実です。この状況からデバッグ実行=ProxyServerの認証なし、と解釈をしてしまったことが間違いの始まりと考えています。恥ずかしながら...お騒がせしてすみません。
私は当該端末でインターネットを利用する際、ふとProxyServerの認証が現われないことに気付くと、その資格情報を消す癖があります(社内で毎回の認証が推奨されているためです)。これも今回の勘違いを生んだ背景でス。この作業後であれば 当該Webフォームを、デバッグ実行であれ、運用環境上のものをブラウザ実行したにせよ 必ずProxyServerの認証は 求められることが確実です。
文面をうまく纏めることができず 申し訳ないのですが
「開発環境(VSのデバッグ実行)と運用環境で 実行スタイル違うあるものの 同一Webフォームを、同一端末同一ブラウザで実行していながらProxyServerの認証有無に違いが現われた理由とは」....の答えですが、
【当方の認識違いで そんなことは有り得ない】 と述べざるを得ません。
本件クローズとさせて頂きます、SuferOnWwwさんはじめ 皆様に混乱を与えたことを深くお詫び申しあげます。
- 編集済み saya24 2019年10月25日 13:03