site_archiver@lists.apple.com Delivered-To: macnetworkprog@lists.apple.com On Apr 8, 2009, at 3:00 AM, Marc Stibane wrote: Am 07.04.2009 um 22:53 schrieb Jim Luther: I wrote this method: - Jim Hopefully in iPhoneOS 3.0... that explains why it happens /always/ in the simulator... - Jim On Apr 7, 2009, at 3:27 AM, Marc Stibane wrote: 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.... Credentials with NSURLCredentialPersistenceNone are not stored in the credential cache. The first thing the code below - setCredential:forProtectionSpace: and - setDefaultCredential:forProtectionSpace: does is get the credential's persistence and if it is NSURLCredentialPersistenceNone, return without doing anything else. -(void)removeCredentialsForUser:(NSString *)userName { NSURLCredentialStorage * credentialStorage = [NSURLCredentialStorage sharedCredentialStorage]; NSDictionary * allcredentials = [credentialStorage allCredentials]; for (NSURLProtectionSpace * protectionSpace in allcredentials) { NSDictionary * credentials = [allcredentials objectForKey:protectionSpace]; for (NSString * aUser in credentials) { NSURLCredential * aCredential = [credentials objectForKey:aUser]; if ([aUser isEqualToString:userName]) [credentialStorage removeCredential:aCredential forProtectionSpace:protectionSpace]; } // for } // for } which I call directly after login succeeds and by setting a breakpoint on the removeCredential:forProtectionSpace: line I can clearly see that my credential was indeed added in connection:didReceiveAuthenticationChallenge: though I set its persistence to none. I have no idea what you're seeing. The code at the beginning of the implementation for setCredential:forProtectionSpace and setDefaultCredential:forProtectionSpace (in CFNetwork) has looked like this since Mac OS X 10.5 and iPhone 2: { CFURLCredentialPersistence persistence = CFURLCredentialGetPersistence (credential); /* do something only if persistence is not kCFURLCredentialPersistenceNone */ if ( persistence != kCFURLCredentialPersistenceNone ) { ... code to add credential to credential storage ... } } What you are seeing a bug in the code that caches persistent HTTP connections between your NSURLConnection requests. The connection cache is holding onto credentials, even if the credential's persistence is none. <rdar://problem/5991692> is tracking that problem (and it was recently fixed Googling and searching this list's archives shows bug reports from 2006-2008... -- I don't know when it'll show up in a release for you). How long does the connection cache currently hold onto connections and their credentials (if the connection requires authentication)? I think it's 30 seconds on Mac OS X, and 3 seconds on iPhone OS. ... and only most times but not always on the device. However I observe rather 5-6 seconds, not 3. There's no way to purge that cache other than restarting the process, or having an error occur on the connection :-/ We worked around that on the server side yesterday: our server now ignores the (old) credentials when no session cookie exists, which gets deleted on logout - so I can login as new user. 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? This email sent to site_archiver@lists.apple.com