Wrong credentials when updated in the Basic Auth fields

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Set Username=user1 and Password=pass1 in the Basic Auth tab fields.
2. Run the web service call, the right credentials are compiled in the 
Authorization: Basic XXXX header
3. Change Username=user2 and Password=pass2 in the Basic Auth tab fields.
4. When run again, the call uses the old credentials and ignores the 
modification

What is the expected output? What do you see instead?
I'd expect the credentials are used on-the-fly and not cached just once

What version of the product are you using? On what operating system?
v 1.2.2 (2) on OSX Lion

Please provide any additional information below.

Original issue reported on code.google.com by brunomed...@gmail.com on 6 Oct 2011 at 10:16

[GoogleCodeExporter]

Interesting. I'm guessing that the provided OS X http client is doing the 
caching itself. I'll look into this.

Original comment by mike.mat...@gmail.com on 22 Oct 2011 at 2:35

[GoogleCodeExporter]

Original comment by mike.mat...@gmail.com on 22 Oct 2011 at 2:38

• Changed state: Accepted

[GoogleCodeExporter]

I'm having trouble reproducing the issue. In your test, are both user1/pass1 
and user2/pass2 valid credentials? I assume you're hitting the same URL? Also, 
the built in client does store cookies... is your server relying on any sort of 
session or state persisted in a cookie?

Original comment by mike.mat...@gmail.com on 1 Nov 2011 at 3:08

[GoogleCodeExporter]

Original comment by mike.mat...@gmail.com on 6 Nov 2011 at 7:56

• Changed state: Open

[GoogleCodeExporter]

Original comment by mike.mat...@gmail.com on 8 Dec 2011 at 3:04

• Changed state: Invalid

[GoogleCodeExporter]

I'm having the same issue as well. It did work fine some time ago, but now it 
appears to be broken and just remembers the username/password I've entered a 
long time ago. The api is fine as I've tested using curl and other rest client. 
Just wish this is fixed, as I really like this app.

Original comment by suv...@gmail.com on 13 Feb 2012 at 10:22

[GoogleCodeExporter]

Suvash, I'm wondering exactly what caused the break... are you hitting the same 
exact URL, or the same domain, or completely different URLs? Is this a problem 
with a URL that had authentication where the username and password have since 
changed since you've been using CocoaRestClient? Do you see any differences in 
behavior if you quit and reopen the program? 

The authentication mechanism I use is actually the built-in authentication that 
is part of Cocoa's library. I'm not crazy about the way it handles auth, so I'm 
not surprised that this has caused some problems for people. It seems to work 
much like a web browser does, where it will cache a successful auth header and 
reuse it when contacting the same domain... but I am surprised that this 
problem would persist between restarts of the app, because the cocoa http 
client remembers auth details between restarts. 

Thanks for the help!

Original comment by mike.mat...@gmail.com on 13 Feb 2012 at 11:16

• Changed state: New

[GoogleCodeExporter]

Maybe it is a cookie problem, which is not handled properly in CocoaRestClient.

Original comment by glenn.sc...@gmail.com on 13 Mar 2013 at 8:52

[GoogleCodeExporter]

The next release will add an option to include pre-emptive Basic Auth with a 
request. I think this should solve a lot of the auth problems people have had. 

Original comment by mike.mat...@gmail.com on 29 Jun 2013 at 5:51

• Changed state: Started

[GoogleCodeExporter]

I have the same issue. See issue 49.
I believe this is not because the client is caching the credentials, but rather 
that the server issued a session ID, which the client is storing and sending in 
subsequent requests. 
When the server sees the session id, it considers the user already 
authenticated and doesn't use the new credentials.

A solution would be to clear/reset the HTTP client before every request. 

Original comment by nash...@gmail.com on 9 Feb 2015 at 10:21