2

私はしばらくの間これを解決しようとしましたが、成功しませんでした。このような質問や、Apple による認証の使用に関する質問や他のブログのような質問は、すべてではありませんが、いくつかの光を当てています。

私が解決したい私の基本的な問題は次のとおりです。

NSURLConnection のデリゲートと NSURLCredential を NSURLProtectionSpace と NSURLCredentialStorage で利用することにより、サーバーに対して正常に認証しています。ただし、NSURLCredential の永続性を NSURLCredentialPersistencePermanent に設定しても、資格情報を初めて提供した後、サーバーからランダムに認証チャレンジ (401、次に 200) を受け取ります。ランダムなことは、意味をなさないものです。

場合によっては機能し、サーバーへの後続の呼び出しで 200 が正常に返されます。その後も機能せず、401 と 200 が返されます。Mike Abdullah は、こ​​こでプロセスをうまく説明しています。したがって、私の最初の推測では、401 認証を返し、200 を取得するプロセスは標準的な手順であり、排除することはできません。ただし、401 を削除できる場合もあります。そのため、何かを見逃しているようです。

私が送信しているリクエストは、いくつかの GET と 2 つの POST です。問題は、1 回の POST で大量のデータがアップロードされることです。401 を取得しても、データは認証後に nirvana にアップロードされ、再度アップロードされます。

私の代替ソリューションは、401 が受信されたときにとにかくデータが送信されないようにすることです。前述のように 401 が返されないことがあるため、これは難しいようです。

これが何らかの意味で理解できない場合は、情報を追加します。私の推測では、NSURLCredential 全体を間違った方法で使用しているか、最初に 401 を取得してから 200 を取得して認証する方法を使用しているため、排除することはできません。

以下の私のコードからの抜粋：

loginCredential = [NSURLCredential credentialWithUser:@"foo" 
                                             password:@"bar"
                                          persistence:NSURLCredentialPersistencePermanent];

NSURLProtectionSpace *loginProtectionSpace = [[NSURLProtectionSpace alloc] initWithHost:@"foo.com"
                                                                                   port:8000 
                                                                               protocol:@"http" 
                                                                                  realm:nil 
                                                                   authenticationMethod:NSURLAuthenticationMethodBasic];
[[NSURLCredentialStorage sharedCredentialStorage] setDefaultCredential:loginCredential 
                                                    forProtectionSpace:loginProtectionSpace]; 
[loginProtectionSpace release];

loginCommunicator = [[LearnCommunicator alloc] initWithMethod:@"login-foo"     
                                                   credential:loginCredential];

このセットアップでは、NSURLConnection のデリゲートがすべて正しく呼び出されます

- (BOOL)connectionShouldUseCredentialStorage:(NSURLConnection*)connection
{
    NSLog(@"connectionShouldUseCredentialStorage user: %@",[userCredential user]);
    return YES;
}

- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace
{
    NSLog(@"canAuthenticateAgainstProtectionSpaceuser: %@",[userCredential user]);
    return YES;
}

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
{
    NSLog(@"didReceiveAuthenticationChallenge previousFailureCount: %i",[challenge previousFailureCount]);  
    if ([challenge previousFailureCount] == 0)
{
    NSLog(@"Challenging...");
    [[challenge sender] useCredential:userCredential forAuthenticationChallenge:challenge];
}
else
{
    NSLog(@"Username and password are incorrect");
    [[challenge sender] cancelAuthenticationChallenge:challenge];
}
}

ご意見をお待ちしております。どうも

EDIT UPDATE 01これは既知の問題のようで、かなり前にバグレポートとして提出されていましたが、解決されていません。NSURLConnection は、「Expect: 100-continue」ヘッダーをサポートしていないようです。これは、正直なところ、大きな失望です。私はこの問題に何時間も取り組んできましたが、すべてをやり直さなければならないことがわかりました。詳細については、バグ レポートを参照してください: http://openradar.appspot.com/5188833

EDIT UPDATE 02この問題に対する私の現在の回避策は、映画データを含む巨大な HTTP POST を実行する直前に認証を行うことです。いくつかのマイナーな XML ファイルもアップロードする必要があるため、映画のアップロードには事前認証を使用します。これはまだ私には醜いように感じますが、物事を進めなければなりません...このトピックに関する意見/知識は引き続き高く評価されます。

4

0 に答える 0