2017-02-24 12 views
1

Alamofireがサーバーにリクエストを送信するときに不正な認証ヘッダーを使用している場合、この問題が発生します。iOS Alamofire Incorrect Authorization Header

初めてユーザー名とパスワードを使用するとすべて正常に動作します。その後、ユーザー名とパスワードをすばやく変更して別のユーザーとして要求を再試行すると、完全に失敗します。 iOSコンソールでHTTPヘッダーを印刷するときは毎回正しいです。しかし、私のサーバーがヘッダーを印刷するときには、iOSコンソールに印刷したヘッダーとは異なります。

ユーザーを変更する前に数分待つとうまくいくようです。しかし、1分以内に行うと、iOSデバイスに印刷された認証ヘッダーと、サーバーが受信する承認ヘッダーが異なります。したがって、新しい認可情報ではなく古い認可情報を使用しています。

以下は私が使用しているコードです。

func reloadData() { 
    print("Reloading data!!") 
    let keychain = KeychainSwift() 

    let email: String = keychain.get("email")! 
    let password: String = keychain.get("password")! 

    URLCache.shared.removeAllCachedResponses() 

    let sessionManager = Alamofire.SessionManager.default 
    sessionManager.session.configuration.requestCachePolicy = .reloadIgnoringLocalCacheData 


    let loginString = String(format: "%@:%@", email, password) 
    let loginData = loginString.data(using: String.Encoding.utf8)! 
    let base64LoginString = loginData.base64EncodedString() 

    print(base64LoginString) 

    let headers: HTTPHeaders = ["Authorization": "Basic \(base64LoginString)"] 



    sessionManager.request("http://IPHERE:3000/api/items", headers: headers).validate().responseJSON { response in 
     switch response.result { 

     case .success(let value): 

      let json = JSON(value) 
      print("JSON: \(json)") 

      for item in json.array! { 

       let title: String? = item["title"].stringValue 
       self.titles.append(title!) 
       self.colors.append(UIColor.blue) 
      } 

      self.tableView.reloadData() 

     case .failure(let error): 
      print ("My Error") 
      print (error) 
      let alertController = UIAlertController(title: "Error", message: "Error, please try again or contact support", preferredStyle: UIAlertControllerStyle.alert) 
      let okAction = UIAlertAction(title: "OK", style: UIAlertActionStyle.default) { (result : UIAlertAction) -> Void in 
      } 
      alertController.addAction(okAction) 
      self.present(alertController, animated: true, completion: nil) 
     } 
    } 
} 

この関数を初めて呼び出すとうまくいきます。 base64LoginStringは正しく、サーバーが受け取るものと一致します。ログアウトして別のユーザー情報を入力すると、base64LoginStringが元のものと異なっていて、正しいと思われます。しかし、サーバーに送信されたときのリクエストには、新しいものではなく古いbase64LoginStringの値が依然としてあります。したがって、サーバーは、第2のユーザーとしてログインしていても、第1のユーザーの情報を返します。

したがって、base64LoginStringの印刷とサーバーが要求を受信するまでの間に何かが失敗します。それはヘッダーや何かをキャッシュするのとほぼ同じですが、それはまったく意味がありません。

参考までに、私はNode、Express、およびPassport.jsを使用してWebリクエストを処理し、バックエンドで認証しています。助けてくれる情報があれば教えてください。

+0

私はAlamofireを使用していないので、私は本当に速いあなたの質問をお読みください。 http://stackoverflow.com/questions/32893800/alamofire-ignore-cache-control-headersとドキュメントを読んでいれば、** 'Response Caching ** レスポンスキャッシュは、次のように処理されます。 URLCacheによるシステムフレームワークレベル。これは、複合メモリ内およびディスク上のキャッシュを提供し、メモリ内とディスク上の両方のサイズを操作できます。 デフォルトでは、Alamofireは共有URLCacheを利用します。それをカスタマイズするには、「セッションマネージャの設定」セクションを参照してください。 –

+0

またはこれ:http://stackoverflow.com/questions/32199494/how-to-disable-caching-in-alamofire –

+0

ええ、私はそれが 'sessionManager.session.configuration.requestCachePolicy = .reloadIgnoringLocalCacheData'がやっていたものだと思っていました。または 'URLCache.shared.removeAllCachedResponses()' –

答えて

0

あなたのシナリオは同じですが、私の場合はキャッシュ結果がクッキーの原因であるかどうかはわかりません。認証リクエストを行う前にすべてのCookieを削除すると(たとえば、ユーザーがサインアウトしたとき)、私のために働きました。私はそれがあなたの問題かもしれないと思うバックエンド私はサインをしているので、要求もノードとエクスプレスを使用しています。

あなたはすべてのクッキーを削除するには、このコードを試すことができます。

let cookieStore = HTTPCookieStorage.shared 
for cookie in cookieStore.cookies ?? [] { 
    cookieStore.deleteCookie(cookie) 
}