|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
This has come up at least once in the archives, but there didn't seem to be a good answer. Hopefully I missed it…
The problem we are hitting is briefly outlined as:
• Perform a https-based request
• Challenge is met with credentials and request works (NSURLCredential set to per-session persistence)
• Delete the app's notion of the account, including removing the keychain entries (and removing credentials from the credential store, to no avail)
• Perform another request and it succeeds… if you do it quickly enough
• If you wait for "a while" the server or NSURLConnection closes off the established connection and the next attempt will properly re-challenge.
NSURLConnection forcing reuse of the established connection seems bad. At best this is confusing, but at worst it seems like a security/data corruption problem. Imagine you have a WebDAV server set up with different ACLs for the same resource. If the client app tries to switch from user A to user B it may accidentally be acting as user A for a few seconds longer than it intended.
NSURLConnection could listen to changes in the credential store and would kill off connections that were using now-deleted credentials. Or, NSURLConnection could provide API to flush the Keep-Alive pool. Most times we *do* want to reuse connections of course, but there needs to be an escape hatch.
Things we've tried:
• Setting the credentials to 'none' persistence: This causes every request to go through an extra 401 challenge and is bad for performance
• Use the older NSURLConnection delegate methods and try to return NO from -connectionShouldUseCredentialStorage: in the case we know we need to re-authorize. This doesn't get called when there is an established connection.
• Set a 'Connection: close' header on a request -- this is kinda too late (we want to close w/o doing a request), but is ignored anyway (other googling indicates NSURLConnection overrides this to be 'keep-alive').
• … a few other things of less savory nature that I'd not want to ship anyway
If I stop my app in the debugger right before the spot where we need to re-authenticate, I can see via 'lsof -i' that two https connections are alive. Waiting a few seconds for the server to kill them off forces the re-authentication to happen.
Logged as radar://11975686
_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.