iOS開發ASIHTTPRequest身分識別驗證

來源:互聯網
上載者:User

本文為大家介紹了iOS開發ASIHTTPRequest身分識別驗證的內容,其中包括為URL指定要使用的使用者名稱和密碼,為request指定要使用的使用者名稱和密碼,將憑據儲存到keychain,將憑據儲存到session中,NTLM授權,使用代理來提供憑據,使用內建的授權對話方塊目前只對iOS有效),在伺服器請求憑據前向伺服器發送憑據等等內容。

ASIHTTPRequest是簡單易用的,它封裝了CFNetwork API。使得與Web伺服器通訊變得更簡單。它是用Objective-C編寫的,可以在MAC OS X和iPhone應用中使用。

你可以查閱ASIHTTPRequest授權流程圖來瞭解ASIHTTPRequest如何找到授權憑據,並將授權憑據應用到request上。

為URL指定要使用的使用者名稱和密碼

 
  1. NSURL *url = [NSURL URLWithString:@"http://www.dreamingwish.com/"]; 
  2. ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 

為request指定要使用的使用者名稱和密碼

 
  1. NSURL *url = [NSURL URLWithString:@"http://www.dreamingwish.com/"]; 
  2. ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
  3. [request setUsername:@"username"]; 
  4. [request setPassword:@"password"]; 

將憑據儲存到keychain

如果開啟了keychainPersistence,所有提供的可用的使用者名稱和密碼將被儲存到keychain中,以後的request將會重用這些使用者名稱密碼,即使你關閉程式後重新開啟也不影響。

 
  1. NSURL *url = [NSURL URLWithString:@"http://www.dreamingwish.com/"]; 
  2. ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
  3. [request setUseKeychainPersistence:YES]; 
  4. [request setUsername:@"username"]; 
  5. [request setPassword:@"password"]; 

如果你使用keychain但是想要自己管理它,你可以在ASIHTTPRequest.h檔案裡找到相關的類方法。

將憑據儲存到session中

如果開啟了useSessionPersistence預設即是如此),ASIHTTPRequest會把憑據儲存到記憶體中,後來的request將會重用這些憑據。

 
  1. NSURL *url = [NSURL URLWithString:@"http://www.dreamingwish.com/"]; 
  2. ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
  3. [request setUsername:@"username"]; 
  4. [request setPassword:@"password"]; 
  5. [request setUseSessionPersistence:YES]; //這一項是預設的,所以並不必要 
  6.  
  7. //將會重用我們的 username 和 password 
  8. request = [ASIHTTPRequest requestWithURL:url]; 

NTLM授權

要使用NTLM授權的Windows伺服器,你還需要指定你要進行授權域。

 
  1. NSURL *url = [NSURL URLWithString:@"http://www.dreamingwish.com/"]; 
  2. ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:url]; 
  3. [request setUsername:@"username"]; 
  4. [request setPassword:@"password"]; 
  5. [request setDomain:@"my-domain"]; 

使用代理來提供憑據

你不一定非要提前指定授權憑據,你還可以讓每個request在無法從session或keychain中找到憑據時向它們的代理請求憑據。如果你要串連到一個你並不清楚授與類型的伺服器時,這是很有用的。

你的delegate必須實現authenticationNeededForRequest:方法,當request等待憑據時,ASIHTTPRequest將會暫停這個request。如果你持有你需要的憑據,那麼先為request設定憑據,然後調用[request retryUsingSuppliedCredentials]即可。如果你想取消授權,調用[request cancelAuthentication],此時,這個request也會被取消。

從1.0.8版開始,一次只能有一個request的delegate收到authenticationNeededForRequest: 或者 proxyAuthenticationNeededForRequest:。當delegate處理第一個request時,其他需要授權的request將會被暫停。如果提供了一個憑據,當前進程中所有其他的request將會假定這個憑據對這個URL有效,並嘗試重用這個憑據。如果delegate取消了授權,並且隊列的shouldCancelAllRequestsOnFailure值為YES,所有其他的request都將被取消它們也不會嘗試請求憑據)。

當進行同步請求時,你不可以使用代理模式來授權。

在較老的版本中,這麼做會導致程式假死,從1.0.8開始,即使你這麼做了,代理函數也不會被調用。

使用內建的授權對話方塊目前只對iOS有效)

這個特性歸功於1.0.8版本的新類ASIAuthenticationDialog 。這個特性主要是用於授權代理後面會介紹到),但是它也可以用來向使用者取得授權憑據。

為了更好的使用者體驗,大多數串連單一服務的)app必須為request的delegate實現authenticationNeededForRequest:方法,或者避免同時使用代理式授權。

most apps that connect to a single service should implement authenticationNeededForRequest: in their request delegates, or avoid the use of delegation-style authentication altogether.

但是,會有一些情況下,為普通的授權使用ASIHTTPRequest的標準授權對話方塊更好:

  • 你不想建立你自己的登入表單
  • 你可能需要從外部資源擷取資料,但是你不清楚你需不需要進行授權

對於這些情況,為request設定shouldPresentAuthenticationDialog為YES,此時,如果你的代理沒有實現

authenticationNeededForRequest:方法,那麼使用者將會看到這個對話方塊。

一次同時只有一個對話方塊可以顯示出來,所以當一個對話方塊顯示時,所有其他需要授權的request將會暫停。如果提供了一個憑據,當前進程中所有其他的request將會假定這個憑據對這個URL有效,並嘗試重用這個憑據。如果delegate取消了授權,並且隊列的shouldCancelAllRequestsOnFailure值為YES,所有其他的request都將被取消它們也不會嘗試請求憑據)。

對於同步請求的request,授權對話方塊不會顯示出來。

這個對話方塊部分模仿了iPhone上Safari使用的授權對話方塊,它包含以下內容:

  • 一段資訊來說明這些憑據是用於websever而非一個proxy)
  • 你將要串連到伺服器的主機名稱或者IP
  • 授權域如果提供的話)
  • 填寫使用者名稱和密碼的地區
  • 當串連到NTLM授權模式的伺服器時,還會包含一個填寫domain的地區
  • 一個說明資訊,指明憑據是否將會被以明文方式發送例如:“只有當使用基於非SSL的基本授權模式時才會以明文方式發送”)

如果你想改變它的外觀,你必須繼承ASIHTTPRequest,並重寫showAuthenticationDialog來顯示你自己的對話方塊或ASIAuthenticationDialog子類。

在伺服器請求憑據前向伺服器發送憑據

IMPORTANT

從1.8.1開始,使用基本授權模式的request時,這個特性的行為改變了。你可能需要修改你的代碼。

在第一次產生request時,ASIHTTPRequest可以先向伺服器發送憑據如果有的話),而不是等伺服器要求提供憑據時才提供憑據。這個特性可以提高使用授權的程式的執行效率,因為這個特性避免了多餘的request。

對於基本授權模式,要觸發這個行為,你必須手動設定request的authenticationScheme為kCFHTTPAuthenticationSchemeBasic:

 
  1. [request setAuthenticationScheme:(NSString *)kCFHTTPAuthenticationSchemeBasic]; 

對於其他授權方案,憑據也可以在伺服器要求之前被發送,但是僅當有另一個request成功授權之後才行。

在以下情況下,你也許想要禁用這個特性:

  • 你的程式可能會一次使用一系列憑據來與伺服器對話
  • 安全性對於你的程式來說非常重要。使用這個特性是相對不安全的,因為你不能在憑據被發送前驗證你是否串連到了正確的伺服器。

要禁用這個特性,這樣做:

 
  1. [request setShouldPresentCredentialsBeforeChallenge:NO];

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.