site_archiver@lists.apple.com Delivered-To: macnetworkprog@lists.apple.com Am 07.11.2007 um 18:52 schrieb Jerry Krinock: That's exactly what I want to do... did you solve your problem in the meantime? -- In a world without walls and fences, who needs windows and gates? _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com Warming up this old, but unfortunately never answered question, which happens to be exactly my problem with an iPhone app: Even if, in response to connection:didReceiveAuthenticationChallenge, I give NSURLConnection a credential with persistence NSURLCredentialPersistenceNone, I still find that subsequent connections to a server do ^not^always^ give me additional connection:didReceiveAuthenticationChallenge messages. On the iPhone, I *never* get a second challenge - even if I delete the credentials from the credentialStore (where they never should have been stored at all, since I use NSURLCredentialPersistenceNone - clearly a bug). Therefore, if I have more than one user account with that server, how can I arbitrarily change accounts in the middle of a session? Because this all goes on under the hood of NSURLConnection, I can't see what's happening with subsequent requests. Either (a) NSURLConnection is sending a stored credential with subsequent requests, or (b) the server is skipping its 401 authentication request, ("I know you"), or (c) NSURLConnection is responding to subsequent 401s with a stored credential. Since I have access to our server after decryption of the https packet, I can confirm it's (a) - NSURLConnection is sending a stored credential with *every* subsequent request - even if I delete it from the credentialStore, so it must be cached elsewhere. If I knew what was going on, (a) (b) or (c) I could at least point my finger and ask some intelligent questions. I can't read the answer using tcpflow because this is https, encrypted. I'd much appreciate any help in any of the above directions. Googling just led me to http://blog.springenwerk.com/2008/11/i-am-currently-building-iphone.html which describes a workaround for http, which doesn't work for https (I guess it works with unencrypted http because the credentials are not sent with every request as with https). This must be a quite common problem (changing user accounts while talking to the same server) - any hints? smime.p7s