匿名アクセス用に構成されたMOSS 07サイトがあります。このサイト内には、匿名アクセスも有効になっているドキュメントライブラリがあります。匿名ユーザーがPDFファイルを使用すると、問題なく読み取りまたはダウンロードできます。ユーザーがOfficeドキュメントをクリックすると、ログインボックスが表示されます。ユーザーは、このボックスを入力せずにキャンセルできます。ログインすると、ドキュメントに移動します。
これはIEで発生しますが、FireFoxでは発生しません。
この質問への参照がWebにいくつかありますが、明確な解決策はありません: http://www.Microsoft.com/communities/newsgroups/en-us/default.aspx?dg=Microsoft。 public.sharepoint.windowsservices.development&tid = 5452e093-a0d7-45c5-8ed0-96551e854cec&cat = en_US_CC8402B4-DC5E-652D-7DB2-0119AFB7C906&lang = en&cr = US&sloc =&p = 1
http://www.sharepointu.com/forums/t/5779.aspx
http://www.eggheadcafe.com/software/aspnet/30817418/anonymous-users-getting-p.aspx
ログインを無効にするにはSharePoint2010からOfficeドキュメントを開くプロンプトを表示するには、web.configで次の設定を行います
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true">
<!-- here's where the magic happens -->
<verbs allowUnlisted="true">
<add verb="OPTIONS" allowed="false" />
<add verb="PROPFIND" allowed="false" />
</verbs>
</requestFiltering>
</security>
</system.webServer>
SharePoint共有ワークスペースがMSWordで有効になっている場合、ユーザーが共有ワークスペースにアクセスまたは作成する権限を持っていない場合、Windowsログインでユーザーにプロンプトを表示することがあります。これをオフにするには、次の手順を実行します。
これで問題が解決した場合は、すべてのMS Officeプログラムで手順を繰り返して、プロンプトを削除します。 (Excel、PowerPoint、Visioなど)
残念ながら、私が見つけた唯一の回避策は、ログインしているユーザーの一部の機能を壊します(複数のファイルをアップロードできない、Outlookに接続するなど)。
それが許容できる場合、または試してみて確認したい場合:
中央管理>アプリケーション管理>アプリケーションセキュリティ>認証プロバイダーで、Webアプリを選択し、プロバイダーを選択します(「デフォルト」の可能性があります)。
クライアント統合の場合は[いいえ]を選択し、設定を保存します。
Web構成を開き、次の行を見つけます<add verb="OPTIONS,PROPFIND,PUT,LOCK,UNLOCK.....
そして動詞OPTIONSを削除します。
つまり、資格情報を求められることはもうありません。これを元に戻すには、両方の変更を元に戻すだけです。
Sharepoint Server 2010では、新世代のSharepointがweb.configで動詞を保持できないため、解決方法が少し変更されています。したがって、メソッドを変更する必要があります。まず、IIS 7.0を開いて、アプリケーションサイトを選択します。画面の中央に多くのアイテムが表示されます。[フィルターの要求]を選択してダブルクリックします。要求フィルターで、次のことができます。 「動詞」を参照してください。OPTIONS動詞とPROPFIND動詞を拒否モードに追加して、最後にサイトをテストできます。Sharepointでサイトのクライアント統合モードを閉じる必要がある場合があります。必要に応じて、サーバーの全体管理でクライアント統合モードを閉じることができます。
URL書き換えモジュールまたはurlscanがある場合は、http403からhttpOPTIONSリクエストを送信するようにソフトウェアを構成します。
[キャンセル]をクリックして問題が発生した場合は... AuthForwardServerList
http://support.Microsoft.com/kb/94328
Officeは、サイトが信頼できる/ローカルであることを認識していないため、資格情報を転送せず、資格情報を提供する機会を提供します。それは機能です....
適切なレジストリキーにサイトをリストすると、不要な資格情報が転送されますが、プロンプトは表示されません。
考えられる原因と解決策: http://support.Microsoft.com/kb/94328
「WindowsVistaまたはWindows7を実行していて、プロキシが構成されていないコンピューターからFQDNサイトにアクセスすると、資格情報を入力するように求められます。」
「たとえば、プロキシが構成されていないWindowsVistaベースのクライアントコンピューターで2007MicrosoftOfficeを使用してMicrosoftOfficeSharePointサイトからMicrosoftOfficeファイルを開くと、認証の入力を求められます。」
これをチェックしてください:匿名ユーザーがSharePointサイトからOfficeドキュメントをダウンロードするときにログインボックスを削除してください
SharePointでエクストラネット/インターネットサイトを開発する場合、匿名アクセスを許可したいことがよくありますが、これはかなりうまく機能します。ただし、匿名アクセスに関してすぐに使用できるエクスペリエンスが失敗する場合が1つあります。それは、ユーザーにMicrosoftOfficeドキュメントのダウンロードを許可する場合です。その場合、IE/Officeはいくつかのログインダイアログをポップアップします。ユーザーがこれらをキャンセルすると、ドキュメントは期待どおりに開きますが、ドキュメントを開くためにユーザーがいくつかのダイアログをキャンセルする必要はありません。
問題は、Officeがインテリジェントにしようとし、Microsoft Office Protocol Discovery要求を発行して、ユーザーに許可されている量を確認しますが、SharePointは、ユーザーがログインするまでアクセスを拒否して応答することです。
私が見つけた解決策は、ユーザーがログインしていない場合にMicrosoft Office Protocol Discovery要求を拒否するHttpModuleを実装することです。これにより、ログインボックスが削除されます。
IEでOfficeドキュメントを開く場合、ActiveXコンポーネントを使用してクライアントアプリケーションを呼び出し、ドキュメントを開くように要求します。他のブラウザでは、ダウンロードは標準のハイパーリンクであり、ブラウザによって処理されます。
これは、検索結果やドキュメントライブラリの標準のリンクされた列でも発生しますか?
私の推測では、Officeクライアントは、匿名アクセスが有効になっている別の場所から基になるドキュメントテンプレートを読み込んでいます。これは、ドキュメントが最初に作成されたテンプレートをロードせずにOfficeクライアントも機能できるため、ドキュメントを開くことができる理由も説明しています。 Word 2007でテンプレートURLを表示するには、[Wordから開発者リボン]オプションを有効にして、リボンの[ドキュメントテンプレート]ボタンをクリックします。
Fiddlerのようなツールを使用する(最初のリンク参照で参照/提案されているように、詳細については http://www.fiddlertool.com/fiddler/ を参照)が根本原因を特定する唯一の効率的な方法です。私が知っているこの種の問題のこれを引き起こしているものは何でもHTTP経由で起こります。 Fiddlerのようなデバッグプロキシは、認証の要求を引き起こしているURL /リソースを正確に示します。
関連するメモとして、プラットフォームの最近のビルドを実行していますか?この問題がMSによってまだ対処されていないことを確認するのが賢明かもしれません。修正プログラムで。私が知っている更新の最良のリストはここにあります: http://www.harbar.net/articles/postsp1.aspx
あなたはWindowsVistaを使っていると思います。この問題はVistaでは発生しましたが、XPでは発生しませんでした。
Microsoftから:Windows Vistaでは、Internet Explorerを使用してWebDAVリソースにアクセスすると、InternetExplorerはWebクライアントサービスを使用します。 Webクライアントサービスは、Windows HTTPサービス(WinHTTP)を使用して、リモートホストへのネットワークI/Oを実行します。 WinHTTPは、ローカルイントラネットサイトで発生する要求に応答してのみユーザー資格情報を送信します。ただし、WinHTTPは、Internet Explorerのセキュリティゾーン設定をチェックして、Webサイトが資格情報の自動送信を許可するゾーンにあるかどうかを判断しません。
プロキシが設定されていない場合、WinHTTPはローカルイントラネットサイトにのみ資格情報を送信します。
注次の例のように、URLのサーバー名にピリオドが含まれていない場合、サーバーはローカルイントラネットサイト上にあると見なされます。 http:// sharepoint/davshare
URLにピリオドが含まれている場合、サーバーはインターネット上にあると見なされます。ピリオドは、FQDNアドレスを使用していることを示します。したがって、プロキシが構成されていない限り、またこのサーバーにプロキシバイパスが指定されていない限り、資格情報はこのサーバーに自動的に送信されません。
これは既知の問題であり、まだ完全には修正されていません。ここにMSDNブログがあります: http://blogs.msdn.com/sharepoint/archive/2007/10/19/known-issue-office-2007-on-windows-Vista-prompts-for -user-credentials-when-opening-documents-in-a-sharepoint-2007-site.aspx
ここに投稿された興味深い回避策があります: http://grounding.co.za/blogs/neil/archive/2008/11/10/workaround-sharepoint-keeps-prompting-for-login-when-creating- office-2007-documents-on-Vista.aspx
最終的には、Vista SP1に含まれているパッチがありますが、レジストリの編集も必要です。最近、Windows VistaSP2クライアントで次の手順を使用してこれを機能させることができました。
レジストリを開きます。次のサブキーに移動します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
AuthForwardServerListという新しいマルチ文字列値を作成し、それに(たとえば)の値を指定します:https://。Contoso.com
http://。dns.live.com
*。Microsoft.com
https://172.169.4.6
次に、WebClientサービスを再起動します。
次の回避策を見つけました。
シンプルにするには:
クライアント統合を無効にする
サイトのweb.configファイルの登録行からOPTIONS動詞を削除します
それはそうではないようです。問題のドキュメントの1つは、.docテンプレートを使用しないExcelファイルです。また、[ドキュメントテンプレート]ダイアログで、それに基づいて新しいWordドキュメントを作成した場合、SharePointテンプレートファイルへのURLが表示されません。テンプレートが「通常」であるとだけ表示されます。また、ドキュメントライブラリレベルでテンプレートを無効にしてみましたが、パスワードの状況は変わりません。
私は解決策を見つけました。まず、inetpubの下にあるWebアプリケーション構成ファイルを開きます。次に、動詞の追加セクションがあります。このセクションでは、インストール時に多くの動詞が追加されました。オプションとProfind動詞を削除し、構成ファイルを保存します。最後に問題をテストして確認します。問題は終了しました。
IE設定を変更することで、これを機能させることができました。
信頼済みサイトにサイトのURLがあります。 [カスタム設定]で、[ユーザー認証]を次のように設定します。現在のユーザー名とパスワードを使用した自動ログオン