Re: Changing Account Mid-Session with HTTP Authentication
Re: Changing Account Mid-Session with HTTP Authentication
- Subject: Re: Changing Account Mid-Session with HTTP Authentication
- From: Marc Stibane <email@hidden>
- Date: Wed, 8 Apr 2009 12:00:18 +0200
Am 07.04.2009 um 22:53 schrieb Jim Luther:
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.
I wrote this method:
-(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.
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).
Hopefully in iPhoneOS 3.0...
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,
that explains why it happens /always/ in the simulator...
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.
- Jim
On Apr 7, 2009, at 3:27 AM, Marc Stibane wrote:
Warming up this old, but unfortunately never answered question,
which happens to be exactly my problem with an iPhone app:
Am 07.11.2007 um 18:52 schrieb Jerry Krinock:
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?
That's exactly what I want to do...
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.
did you solve your problem in the meantime?
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?
--
In a world without walls and fences,
who needs windows and gates?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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