Re: RESTful API's - Easy way to interact?
Re: RESTful API's - Easy way to interact?
- Subject: Re: RESTful API's - Easy way to interact?
- From: Peter Burtis <email@hidden>
- Date: Sat, 31 May 2008 12:31:01 -0400
Question: Is there a way to set the credentials before you initiate
the request? Or a way to force the request to use credentials even if
the site doesn't return an Authentication Required response? I can't
find one.
And because of this I've ended up rolling my own Authentication scheme
for REST calls as Jeremy describes more than once. Here are the
issues that have made me do it:
A) Some REST APIs never return the Authentication Required header,
they just fail, or return different data, without credentials
included, and then the callback never gets called.
B) IIRC, if an item for the site/realm you're authenticating exists in
the keychain, it is always used and your class never hears about or
has any say in authentication at all. There have been times when
using the name/password set by the user in Safari has not been
appropriate for my use.
C) When there is a password set in the keychain, and it's wrong for
whatever reason, NSURLConnection behaves strangely for me. The
connection:didReceiveAuthenticationChallenge: doesn't get called at
all, and I just get a loop of requests to access the keychain which
seemingly never ends.
D) If you set your credentials as
NSURLCredentialPersistenceForSession, then you're stuck with only
using one set of credentials for each authentication realm. There
have been plenty of times when I've needed to use different
credentials in the same realm. (Handling multiple user accounts from
one app, mostly.) Or am I misunderstanding the word session in this
context?
E) If, on the other hand, you set credentials as
NSURLCredentialPersistenceNone, my understanding of it is that every
request you send ends up actually generating two HTTP requests and,
assuming the remote site doesn't allow keep-alive connections, two
connections--one to discover that authentication is necessary, and
another with the correct credentials. Depending on the frequency of
requests, that's a lot of overhead.
I just end up setting the header before the request goes out, which
seems easy enough. Is there a preferred way of handling this?
-Pete
On May 31, 2008, at 11:04 AM, Jeremy wrote:
Jens,
Thanks for that bit. And I am a native english speaker. It was late
when I typed that. :D But Thanks for NSURLConnection suggestion and
will look into it.
Jeremy
"I have often felt that programming is an art form, whose real value
can only be appreciated by another versed in the same arcane art;
there are lovely gems and brilliant coups hidden from human view and
admiration, sometimes forever, by the very nature of the process.
You can learn a lot about an individual just by reading through his
code, even in hexadecimal." - Unknown
On May 31, 2008, at 2:50 AM, Jens Alfke wrote:
On 30 May '08, at 7:16 PM, Jeremy wrote:
Now, I need to figure out how to use set GET, but I think that is
working. The problem and it is crashing is because it is being
encoded by every other method.
What? That sentence was incomprehensible. Apologies if you're not a
native English speaker, but if we can't understand your
descriptions we can't help you...
Here is an example in "pseudo code":
'Basic ' + Base64.encode(username + ':' + password)
Don't try to roll your own authentication code. NSURLConnection
already supports authentication, including digest mode and Keychain
integration. Read the documentation on the delegate methods,
including the authentication-related ones.
—Jens
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
@glossysheep.com
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden