Path.GetTempFileName — ディレクトリ名が無効です
https://stackoverflow.com/questions/55411
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
特定のサーバーで Path.GetTempFileName を使用すると、ディレクトリ名が無効であるというエラーが発生するという問題が発生します。さらに調査すると、c:\Documents andsetting\computername\aspnet\local settings emp (Path.GetTempPath を使用して検出) にファイルを書き込もうとしていることがわかります。このフォルダーは存在するため、これは asp.net アカウントに関するアクセス許可の問題であると思われます。
Path.GetTempFileName は C:\Windows\Microsoft.NET\Framework\v2.0.50727 emporaryasp.net ファイルを指しているはずだという人もいます。
また、この問題は、サーバーにインストールされる IIS と .NET の順序が原因である可能性があるとも言われています。一般的な「aspnet_regiis -i」を実行し、フォルダーなどのセキュリティをチェックしました。この時点で私は行き詰まっています。
誰かこれについて光を当てられますか？
**更新:**フォルダーへの「IUSR_ComputerName」アクセスを提供するとうまくいくことがわかりました。それは正しい手順ですか?過去にそのようなことをした覚えはないようですが、明らかに、セキュリティを維持するためにベスト プラクティスに従いたいと考えています。結局のところ、これはファイルのアップロード プロセスの一部です。
解決
これはおそらく、なりすましと、さまざまな認証方法の不一致が組み合わされて発生していると考えられます。
たくさんの作品があります。一つずつ見ていきたいと思います。
なりすまし スレッドを実行しているユーザー アカウントを「一時的に」切り替える手法です。基本的に、スレッドは、なりすまし対象のアカウントと同じ権限とアクセス権を一時的に取得します (それ以上でもそれ以下でもありません)。スレッドは Web ページの作成が完了するとすぐに元のアカウントに「戻り」、次の呼び出しに備えます。この手法は、Web サイトにログインしているユーザーのみがアクセスできるリソースにアクセスするために使用されます。コンセプトを少し待ってください。
現在、デフォルトでは、ASP.NET は というローカル アカウントで Web サイトを実行します。 アスプネット. 。繰り返しますが、デフォルトでは、ASPNET アカウントと Administrators グループのメンバーのみがそのフォルダーに書き込むことができます。一時フォルダーはそのアカウントの権限下にあります。これはパズルの 2 番目のピースです。
なりすましは単独で行われるわけではありません。web.config で意図的にオンにする必要があります。
<identity impersonate="true" />
この設定が欠落しているか false に設定されている場合、コードは上記の ASPNET アカウントで純粋かつ単純に実行されます。エラー メッセージを考えると、impersonation=true になっていると思われます。それは何の問題もありません！なりすましには、ここで説明した以上の利点と欠点があります。
質問が 1 つ残っています。なりすましを使用する場合、 どのアカウントがなりすましされるのか?
web.config でアカウントを指定しない限り (アイデンティティ要素の完全な構文はこちら)、偽装されたアカウントは、IIS が ASP.NET に引き渡したものです。それは、ユーザーがサイトでどのように認証されたか (または認証されなかったか) によって異なります。それが 3 番目で最後の作品です。
IUSR_ComputerName アカウントは、IIS によって作成された権限の低いアカウントです。デフォルトでは、このアカウントは Web 通話を実行するアカウントです ユーザーが認証できなかった場合. 。つまり、ユーザーは「匿名」としてアクセスします。
要約すると、これがあなたに起こっていることです:
ユーザーが Web サイトにアクセスしようとしていますが、IIS は何らかの理由でそのユーザーを認証できませんでした。匿名アクセスがオンになっているため (そうしないと、IUSRComputerName が一時フォルダーにアクセスしているのが表示されません)、IIS はユーザーに一般ユーザーとしてのアクセスを許可します。ASP.NET コードが実行され、この汎用 IUSR___ComputerName "guest" アカウントになりすまします。ただし、コードは、独自の一時フォルダーを含め、ASPNET アカウントがアクセスできたものにアクセスできなくなります。
IUSR_ComputerName にフォルダーへの書き込みアクセスを許可すると、症状は解消されます。
しかし、それは単なる症状です。見直す必要があります なぜその人は「匿名/ゲスト」として来るのですか？
考えられるシナリオは 2 つあります。
a) 認証に IIS を使用するつもりでしたが、一部のサーバーの IIS の認証設定が間違っています。
その場合、通常の認証メカニズムが実行されるように、それらのサーバーで匿名アクセスを無効にする必要があります。場合によっては、その一時フォルダーへのアクセスをユーザーに許可するか、代わりにユーザーが既にアクセス権を持っている別のフォルダーを使用する必要があることに注意してください。
私はこのシナリオに何度も取り組んできましたが、率直に言って、Temp フォルダーを省略した方が頭痛の種は少なくなります。サーバーに専用のフォルダーを作成し、適切なアクセス許可を設定して、その場所を web.config に設定します。
b) とにかくユーザーを認証したくなかった、または ASP.NET フォーム認証 (IIS の匿名アクセスを使用して IIS のチェックをバイパスし、ASP.NET が認証を直接処理できるようにする) を使用したかった場合
このケースはもう少し複雑です。
IIS に移動し、「匿名アクセス」以外のすべての形式の認証を無効にする必要があります。デバッガーでは統合認証を有効にする必要があるため、開発者向けボックスではこれを実行できないことに注意してください。したがって、デバッグ ボックスは実際のサーバーとは少し異なる動作をします。ただそれに気づいてください。
次に、偽装をオフにするか、あるいは逆に、web.config で偽装するアカウントを指定するかを決定する必要があります。Web サーバーに外部リソース (データベースなど) が必要ない場合は、最初の操作を実行します。データベース (またはその他の外部リソース) にアクセスできるアカウントで Web サイトを実行する必要がある場合は、後者を実行してください。
偽装するアカウントを指定するには、さらに 2 つの選択肢があります。1 つは、IIS にアクセスして、「匿名」アカウントを、IIS が管理するアカウントではなく、リソースにアクセスできるアカウントに変更することです。2 番目の方法は、アカウントとパスワードを暗号化してレジストリに隠しておくことです。この手順は少し複雑であり、この説明の範囲を超えています。
幸運を！
他のヒント
一時ファイルに書き込んでいたコンソール アプリを診断中に、このエラーが発生しました。テスト反復の 1 つで、「白紙の状態」で実行するために、一時ファイル/ディレクトリをすべてパージしました。この自ら招いた問題は、ログアウトして再度ログインすることで解決しました。
使用できます Path.GetTempPath() どのディレクトリに書き込もうとしているかを調べます。
ASP.Net アプリケーションの 1 つで同じ問題が発生しました。私は得ていました Path.GetTempPath() しかし、それは次の例外をスローしていました:
「ファイル "C:\Windows emp\somefilename" に書き込めませんでした。例外:パス「C:\Windows emp\somefilename」へのアクセスが拒否されました。」
このページでいくつかの提案を試しましたが、何も役に立ちませんでした。
最終的に、Web サーバー (IIS サーバー) にアクセスし、サーバーの「C:\Windows emp」ディレクトリのアクセス許可を変更して、「Everyone」ユーザーに完全な読み取り/書き込みアクセス許可を付与しました。
そして最終的に、例外は解消され、ユーザーはアプリケーションからファイルをダウンロードできるようになりました。ふう！
