Understanding the ASIHTTPRequest authentication process

HTTP Authentication is one area where ASIHTTPRequest has had a fair number of changes recently. It can be difficult to understand how where credentials come from, and when they are applied and sent to the server.

Credentials for authentication can come from several places:

• the username, password and domain (NTLM only) properties of a request
• The url (eg: http://ben:copsey@allseeing-i.com)
• The session store (a list of credentials that have been used before in the same application session)
• The keychain. On Mac OS X, ASIHTTPRequest can use credentials stored by other applications, if the user agrees to allow access. On iPhone OS, ASIHTTPRequest can only read credentials that were stored by the same application.
• Request delegates that respond to authenticationNeededForRequest: can set credentials on the request when this method is called
• ASIAuthentication dialogs (when shouldPresentAuthenticationDialog is true)

Credentials can be applied to a request in two ways:

1. Before a request is sent
   When shouldPresentCredentialsBeforeChallenge is true, as is the default, requests can build an authorization header and apply it to the request before it is sent. The header is added only when the username or password properties are set on the request, or there are credentials requests that have previously used to talk to the same server in the session store. If a username and password are set on the request, ASIHTTPRequest can only create a basic authentication Authorization header, NTLM and Digest are not supported.
2. After a challenge from the server
   If no credentials or the wrong credentials are sent to the server, it may respond with a 401 status code. ASIHTTPRequest will then attempt to find credentials it can use to resend the request.

Download PDF How its work:Here

Reference From:http://allseeing-i.com/
ads: ebay