4

MVC アプリから、この SO の質問への回答に従って、認証付きの iCal サブスクリプションを調達しています。

認証を使用して ASPNET MVC で iCalendar ファイルを提供する

iCal ストリームは、DDay.iCal ライブラリを使用して DB 内のイベントから動的に作成されています。

このソリューションは、ローカル開発サーバーで問題なく動作します。OSX カレンダーと Outlook の両方が、アプリを購読して更新を受け取ることができます。

ただし、Web ホストの共有サーバーでは、カレンダーと Outlook の両方で認証が失敗します。つまり、（正しい）ものが失敗した後、両方ともユーザーとパスワードを求め続けます。

編集:カレンダーの URL にブラウザーを向けると、認証も失敗します。

編集: 奇妙なことに、Firefox は認証を行い、iCal ファイルを取得します。Safari、Chrome、および IE は認証に失敗します。

同じ資格情報を使用してカレンダーの URL に curl を指定すると、成功します (つまり、目的の iCal ファイルを取得できます)。もちろん、同じ資格情報を使用して MVC アプリにログインすることもできます。

編集 — 何が起こっているかはわかっていると思いますが、修正方法がわかりません。私のOnAuthorization()追加のみですWWW-Authentication Basicが、Fiddler では、3 種類の認証が提供されていることがわかります。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Secure Calendar"
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
... etc ...

この時点で、Firefox のみが Basic Authorization で応答し、成功します。

GET <<URL>> HTTP/1.1
...
Authorization: Basic <<encoded credentials>>

IE は Negotiate で応答しますが、失敗します

GET <<URL>> HTTP/1.1
...
Authorization Negotiate <<encoded stuff>>

他の 2 つを追加しているのは誰ですか?どうすれば停止できますか? サーバー応答の詳細は次のとおりです。

HTTP/1.1 401 Unauthorized
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: text/html
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 3.0
WWW-Authenticate: Basic realm="Secure Calendar"
X-AspNet-Version: 4.0.30319
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-Powered-By-Plesk: PleskWin
Date: Tue, 23 Oct 2012 13:27:48 GMT

ありがとう、エリック

4

5 に答える 5

5

ハハ、答えは IIS の構成にありました。

ホストの管理者に他の認証をオフにするように依頼したところ、iCal フィード以外はすべて壊れてしまいました。

現在、彼らは再びいくつかをオンに戻し、MVC サイトと認証付きのカレンダー フィードが機能するようになりました。とても、とても大きな笑顔。

最終的に得られた IIS 構成は次のとおりです。

Name                        Status         Response Type
Anonymous Authentication    Enabled
ASP.NET Impersonation       Disabled
Basic Authentication        Disabled       HTTP 401 Challenge
Digest Authentication       Disabled       HTTP 401 Challenge
Forms Authentication        Enabled        HTTP 302 Login/Redirect
Windows Authentication      Enabled        HTTP 401 Challenge

なぜこれが機能するのか、または他に何が壊れる可能性があるのか​​ はわかりませんが、今日は満足しています.

于 2012-10-24T03:52:15.220 に答える
3 
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

Windows 認証で使用されます。最終的に匿名認証を有効にしたため、すべてのWWW-Authenticateヘッダーは表示されません。

于 2012-10-24T06:22:10.970 に答える
0

これに対する遅ればせながらの回答として、カスタム メッセージ ハンドラーを作成することでこれを処理することもできます。

メッセージ ハンドラーは継承元であり、そのメッセージ ハンドラーにDelegatingHandler追加する必要があります。HttpConfigurationMessageHandlers

これは次のようになります。

public class EnsureNoAuthenticationHeaderHandler : DelegatingHandler 
{
    async protected override Task<HttpResponseMessage> SendAsync( HttpRequestMessage request, CancellationToken cancellationToken ) 
    {
        var response = await base.SendAsync( request, cancellationToken );
        if ( response.StatusCode == System.Net.HttpStatusCode.Unauthorized ) 
        {
            response.Headers.Remove( "WWW-Authenticate" );
        }
        return response;
    }
}

そして、次のように HttpConfiguration に登録します

private void Register( HttpConfiguration configuration ) 
{
    configuration.MessageHandlers.Add( new EnsureNoAuthenticationHeaderHandler() );
}

おそらくグローバル構成から呼び出すでしょう。メッセージ ハンドラーはルートに直接アタッチすることもできます。そのため、どこでも使用できるようにしたくない場合は、MSDNのリンクされた記事を参照して詳細を確認してください。

于 2019-04-29T15:28:44.913 に答える