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: Jim Luther <email@hidden>
- Date: Tue, 7 Apr 2009 13:53:07 -0700
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.
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 -- 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. There's no
way to purge that cache other than restarting the process, or having
an error occur on the connection :-/
- 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?
_______________________________________________
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