Actually, the authentication part (and "which approach" discussion/decision with stake-holder) has not been implemented yet. But it is in the TODO pipeline, and not at the top of the TODO list yet.
On May 5, 2010, at 5:28 PM, Johnny Miller wrote: > Hi Kieran, > > I was searching my email on this topic and I found this thread. Would you be > willing to share your solution that you ended up using for wiring the Rest > server to your Cappuccino app? > > Thanks, > > Johnny > > > On Mar 19, 2010, at 3:28 PM, Kieran Kelleher wrote: > >> Actually, I like API keys myself. Simple and easy. >> >> Now API keys are ideal for cases where the user wants to change her password >> for her account, but her API key still stays the same and continues working >> for whatever client app is using it ....... actually Merchant Services sites >> work like this, or at least the ones I have implemented clients for ...... >> commonly the HTTPS form post includes 3 key-value pairs for MerchantID, >> UserID and User PIN. Hey, if it is good enough for Credit Card processing, >> it should be OK for my REST services! >> >> Now what about the case where API keys are inconvenient for the end client >> user. For example, I have a Gianduia Cappuccino app where the user goes to a >> site, logs in and works away in his Cappuccino app with occasional REST >> requests to GET and manipulate serverside data. I guess we could store his >> userid and SHA-hashed password locally in the Cappuccino app and send the >> user id and SHA hashed password in two of the headers with every HTTPS REST >> request ..... is that common practice for this scenario? >> >> -Kieran >> >> >> On Mar 19, 2010, at 11:01 AM, Mike Schrag wrote: >> >>> i'm a fan of API keys, personally ... most "web 2.0" sites use them and >>> it's pretty straightforward to hook up. >>> >>> ms >>> >>> On Mar 19, 2010, at 10:44 AM, Kieran Kelleher wrote: >>> >>>> First, Wonder's ERRest.framework rocks! Thank you again Mike Schrag! .... >>>> and that is not my first time saying that in the last couple of days :-) >>>> >>>> Second, I would like to get some opinions on REST authentication >>>> approaches. There seems to be a plethora of approaches out there. >>>> >>>> Probably the "easiest" for us WO devs is to make the user call a https >>>> login URL first to authenticate with userid, password and if successful, >>>> hand them back a response with Session cookie and just use https and >>>> existingSesson in cookie in our ERX route request handling for the >>>> duration of the session. While easy for us, this might be a little >>>> inconvenient for the client developer though since they must now manage >>>> their session key and handle retries if the session has timed out, etc. >>>> >>>> So, if I were trying to get really simple (for the >>>> client/client-developer) stateless REST authentication, whereby the client >>>> did not have to maintain a session and every request has the authorization >>>> aspect, then what are the best approaches? Anyone have any hands-on >>>> experiences to share? >>>> >>>> The simplest approach seems to be the API Key, but it seems a little >>>> insecure ..... like a permanent session. For example these guys use an api >>>> key and, if I am not mistaken, it seems they use it over HTTP, so any >>>> traffic sniffer could pick it up: >>>> http://www.campaignmonitor.com/api/method/campaign-create/ >>>> Nevertheless this is obviously the easiest way for a client to >>>> interoperate I would think..... and if done over https, then it should be >>>> both secure and easy for a client implementation? Thoughts? >>>> >>>> Then you look at Amazon's authentication. That seems like a very secure >>>> solution? Any thoughts? >>>> http://docs.amazonwebservices.com/AmazonS3/latest/index.html?RESTAuthentication.html >>>> >>>> BTW, the java implementation for generating the ever-changing >>>> Auhtorization code for AWS Auth can be found at: >>>> ERAttachment/Sources/com.amazon.s3.AWSAuthConnection.addAuthHeader(HttpURLConnection, >>>> String, String) >>>> >>>> So, thoughts, opinions? >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>>> >>>> This email sent to [email protected] >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/jlmiller%40kahalawai.com >> >> This email sent to [email protected] > > Johnny Miller > Kahalawai Media Corp > http://www.kahalawai.com > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
