私のアプリのバックエンドへのAPI呼び出しをしている間、私は問題に遭遇しています。
CredStore - performQuery - Error copying matching creds. Error=-25300, query={
atyp = http;
class = inet;
"m_Limit" = "m_LimitAll";
ptcl = http;
"r_Attributes" = 1;
srvr = "myappsurl.com";
sync = syna;
}
これが何を引き起こしているのか、あるいはCredStoreが何をしているのかわからないので、私は少し迷っています。 iOSでCredStoreはどのような目的に役立ちますか?
このエラーは、未知のURLCredential
に対してURLCredentialStorage
からURLProtectionSpace
を検索しようとしたときに発生します。例えば.
let protectionSpace = URLProtectionSpace.init(Host: Host,
port: port,
protocol: "http",
realm: nil,
authenticationMethod: nil)
var credential: URLCredential? = URLCredentialStorage.shared.defaultCredential(for: protectionSpace)
作り出す
CredStore - performQuery - Error copying matching creds. Error=-25300, query={
class = inet;
"m_Limit" = "m_LimitAll";
ptcl = http;
"r_Attributes" = 1;
srvr = Host;
sync = syna;
}
保護スペースの資格を与えます。
let userCredential = URLCredential(user: user,
password: password,
persistence: .permanent)
URLCredentialStorage.shared.setDefaultCredential(userCredential, for: protectionSpace)
次回資格情報を取得しようとしたときにエラーが消えます。
これが何を引き起こしているのか、あるいはCredStoreが何をしているのかわからないので、私は少し迷っています。 iOSでCredStoreはどのような目的に役立ちますか?
IOSの認証情報ストレージを使用すると、ユーザーは証明書またはパスワードに基づく認証情報を一時的または恒久的にキーチェーンに安全にデバイスに保存できます。
バックエンドサーバーで何らかの認証が行われており、そのサーバーからアプリへの認証確認が要求されている(資格情報が存在しない)と思われます。
URLCredentialStorage
からnilを返すことは有効な応答であるため、おそらく無視しても問題ありません。
これは転送エラーです。plistファイルに次のような転送許可を追加しましょう。
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
注意してください。アプリからどのサーバーにも接続できます。先に進む前に、App Transport Securityの詳細を読んでください。 @keziのコメントを見る
AVPlayerを使用しているときにこのエラーが発生した場合は、メインスレッドで.play()を呼び出してください。
Alamofireでリクエストを実行したときになぜこのエラーが発生するのかよくわかりませんが、HTTPヘッダに何らかのトークンを使用してAPIリクエストを行う場合は、認証情報ストアはまったく必要ないかもしれません。だから私たちは私たちの要求のためにそれを無効にすることができます:
let configuration = URLSessionConfiguration.default
configuration.httpAdditionalHeaders = ourHeaders
// disable default credential store
configuration.urlCredentialStorage = nil
let manager = Alamofire.SessionManager(configuration: configuration)
...
このような変更後もエラーはありません。
私と同じ問題が起こり、あなたのAPI URLのURLの最後に "/"が含まれていない場合、iOSは "Authorization"値をサーバーに送信しません。そのため、コンソールに問題の投稿のようなメッセージが表示されます。
そのため、URLの最後に「/」を追加するだけです。
https://example.com/api/devices/
さて、私はこのエラーを抱えていて、私のRuby on Railsアプリケーションと対話するときに長い間(何年も)それと戦いました。
承認された回答で説明されているようにデフォルトの資格情報を設定しましたが、それでもエラーが発生し、資格情報を提供するためにdidReceiveChallenge応答に依存していました。
しかし!解決策が見つかりました。
ProtectedSpaceフィールドがRuby on RailsサーバーからのAuthorizationチャレンジと一致しないことを狙って作業していました - そして私はrealmフィールドを調べました。
私は最初にサーバのレスポンスヘッダをプリントアウトすることから始めました、そしてそれらを調べることはできましたが、それらはレルムフィールドを含んでいたであろうWWW-Authorizationフィールドを含みませんでした。
私はこれがRailsアプリがレルムを指定していないことが原因だと思ったので、Rails側のことを見始めました。
の呼び出しでレルムを指定できることがわかりました。
authenticate_or_request_with_http_basic
...これはHTTP Basic認証に使用しています。
まだレルムを指定していないので、追加します。
authenticate_or_request_with_http_basic("My Rails App")
次に、対応する文字列をprotectionSpaceに追加しました。
NSURLProtectionSpace *protectionSpace =
[[NSURLProtectionSpace alloc] initWithHost:@"myrailsapp.com"
port:443
protocol:NSURLProtectionSpaceHTTPS
realm:@"My Rails App"
authenticationMethod:NSURLAuthenticationMethodHTTPBasic];
ほら!それはうまくいった、そして私はもう手に入らない、
CredStore - performQuery - Error copying matching creds. Error=-25300
Railsアプリケーションでレルムを指定した後でも、それがHTTPヘッダーで渡されているのがわかりません。理由はわかりませんが、少なくとも機能します。
この問題を解決するために、URLを含む文字列を編集しました。
var myUrl = "http://myurl.com"
myUrl = myUrl.addingPercentEncoding(withAllowedCharacters: .urlFragmentAllowed)!
let url = URL(string: myUrl)
このエラーが表示された原因は、Authorizationヘッダーの "Bearer"とアクセストークンの間に誤って2つのスペースを使用していたためです。
間違っている:
request.setValue("Bearer \(accessToken)", forHTTPHeaderField: "Authorization")
正しい:
request.setValue("Bearer \(accessToken)", forHTTPHeaderField: "Authorization")
単純な間違いですが、見つけるのに時間がかかりました。
このエラーは、制限が厳しすぎる可能性があるコンテンツセキュリティポリシー(CSP)によっても発生する可能性があります。私たちの場合は、ほぼ完全にオープンで、すべてを許可するCSPが必要でした。 CSPを開くことは大きなセキュリティ上の問題になる可能性があることに注意してください(アプリで実際に何をしているかによって異なります)。
私の場合は、Stripe SDKをAPIキーで初期化していませんでした。
STPPaymentConfiguration.shared().publishableKey = publishableKey
Stripe操作の場合、エラーログを印刷できれば、わかりやすいでしょう。
print(error.debugDescription)
Webビュー内でhttpページを開こうとしたときにこの問題が発生しました。しかし、このページには最初に開かれたポップアップが含まれていました。
バックエンドチームがこのポップアップを削除したとき、すべてうまくいった。