Re: REST authentication
Thanks to all. I am thinking about using SSO CAS Authentication too. Did you have an example on how to implement it ? Ray Envoyé depuis iCloud Le 6 oct. 2014 à 02:54, Pascal Robert a écrit : It’s all on wocommunity.org and slideshare.net. > Hi List, > > The answer about REST auth interests me too. > > Can I download WOWODC 2012 on iTune? > > Thanks. > > Envoyé de mon iPad > > Le 4 oct. 2014 à 21:57, Pascal Robert a écrit : > > > Check my presentations from WOWODC 2012. > > > > Envoyé de mon iPhone > > > > Le 2014-10-04 à 10:02, Gabor Raz a écrit : > > > > > Hi Guys, > > > > > > I normally make my own projects with Node.js. Most of them with the MEAN.IO framework. But I also came in touch with WebObjects / Project WOnder during my training. > > > > > > Now I would like to convert a node application into a wonder application. And here I have a question. How do I create a authentication via REST and make my routes only available for authenticated users? > > > > > > Thanks in advance > > > Gabor Raz > > > ___ > > > Do not post admin requests to the list. They will be ignored. > > > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > > > Help/Unsubscribe/Update your Subscription: > > > https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > > > > > This email sent to prob...@macti.ca > > ___ > > Do not post admin requests to the list. They will be ignored. > > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/webobjects-dev/rnaneon%40me.com > > > > This email sent to rnan...@me.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST authentication
It’s all on wocommunity.org and slideshare.net. > Hi List, > > The answer about REST auth interests me too. > > Can I download WOWODC 2012 on iTune? > > Thanks. > > Envoyé de mon iPad > > Le 4 oct. 2014 à 21:57, Pascal Robert a écrit : > >> Check my presentations from WOWODC 2012. >> >> Envoyé de mon iPhone >> >> Le 2014-10-04 à 10:02, Gabor Raz a écrit : >> >>> Hi Guys, >>> >>> I normally make my own projects with Node.js. Most of them with the MEAN.IO >>> framework. But I also came in touch with WebObjects / Project WOnder during >>> my training. >>> >>> Now I would like to convert a node application into a wonder application. >>> And here I have a question. How do I create a authentication via REST and >>> make my routes only available for authenticated users? >>> >>> Thanks in advance >>> Gabor Raz >>> ___ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >>> >>> This email sent to prob...@macti.ca >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/rnaneon%40me.com >> >> This email sent to rnan...@me.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST authentication
On 06/10/2014, at 8:45 AM, John Huss wrote: > REST basically just means HTTP, so the answer is to use HTTP auth, most > likely BASIC auth. This can be done two ways: > > 1) If your apps are fronted by Apache (which they probably are), then you can > use Apache's bult-in authorization functionality, the simplist form of which > is just to declare users in flat text files. There are probably many other > ways to store the user info. > > 2) You can do the auth inside your app. Globally in > Application.dispatchRequest or more granularly in your route class (which is > just a DirectAction subclass) in DirectAction.performAction. You just have > to read the Authorization header and parse it, then check for the user and > password in your database or whatever. I don't believe there is an > implementation in Wonder, but if not there should be. > Hi list, We do something similar in our apps using ERRest : insert a class between your entity controller classes and ERXDefaultRouteController (or similar), extend that class from the Controllers you care about, override performActionNamed() and authenticate either the WOSession or another method of authentication (HMAC account and signatures for example). I insert the authentication credentials/session info into the rest context userInfo, so I can do further EO based checks against a rest verb action (DELETE, PUT, etc) in the controller of the EO. Also, the rest context userInfo helps you in your ERXAbstractRestDelegate sub classes. You can retrieve the, for example, external ERP system credentials from the rest context to facilitate your: createObjectOfEntityWithID and objectOfEntityWithID and primaryKeyForObject methods. Helps when you are creating or fetching EOs and need to build-a-relationship or check or filter against a Organisation or Company object, for example. Lastly, that default controller subclass comes in handy if you want to finesse any OPTIONS calls, or modifying any header values in egress or ingress, and similar common operations. Regards, Matt -- http://logicsquad.net > > On Sat, Oct 4, 2014 at 9:01 AM, Gabor Raz wrote: > Hi Guys, > > I normally make my own projects with Node.js. Most of them with the MEAN.IO > framework. But I also came in touch with WebObjects / Project WOnder during > my training. > > Now I would like to convert a node application into a wonder application. And > here I have a question. How do I create a authentication via REST and make my > routes only available for authenticated users? > > Thanks in advance > Gabor Raz > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com > > This email sent to johnth...@gmail.com > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/matt%40logicsquad.net > > This email sent to m...@logicsquad.net ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST authentication
REST basically just means HTTP, so the answer is to use HTTP auth, most likely BASIC auth. This can be done two ways: 1) If your apps are fronted by Apache (which they probably are), then you can use Apache's bult-in authorization functionality, the simplist form of which is just to declare users in flat text files. There are probably many other ways to store the user info. 2) You can do the auth inside your app. Globally in Application.dispatchRequest or more granularly in your route class (which is just a DirectAction subclass) in DirectAction.performAction. You just have to read the Authorization header and parse it, then check for the user and password in your database or whatever. I don't believe there is an implementation in Wonder, but if not there should be. On Sat, Oct 4, 2014 at 9:01 AM, Gabor Raz wrote: > Hi Guys, > > I normally make my own projects with Node.js. Most of them with the > MEAN.IO framework. But I also came in touch with WebObjects / Project > WOnder during my training. > > Now I would like to convert a node application into a wonder application. > And here I have a question. How do I create a authentication via REST and > make my routes only available for authenticated users? > > Thanks in advance > Gabor Raz > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/webobjects-dev/johnthuss%40gmail.com > > This email sent to johnth...@gmail.com > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST authentication
Hi List, The answer about REST auth interests me too. Can I download WOWODC 2012 on iTune? Thanks. Envoyé de mon iPad > Le 4 oct. 2014 à 21:57, Pascal Robert a écrit : > > Check my presentations from WOWODC 2012. > > Envoyé de mon iPhone > >> Le 2014-10-04 à 10:02, Gabor Raz a écrit : >> >> Hi Guys, >> >> I normally make my own projects with Node.js. Most of them with the MEAN.IO >> framework. But I also came in touch with WebObjects / Project WOnder during >> my training. >> >> Now I would like to convert a node application into a wonder application. >> And here I have a question. How do I create a authentication via REST and >> make my routes only available for authenticated users? >> >> Thanks in advance >> Gabor Raz >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >> >> This email sent to prob...@macti.ca > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/rnaneon%40me.com > > This email sent to rnan...@me.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST authentication
Check my presentations from WOWODC 2012. Envoyé de mon iPhone > Le 2014-10-04 à 10:02, Gabor Raz a écrit : > > Hi Guys, > > I normally make my own projects with Node.js. Most of them with the MEAN.IO > framework. But I also came in touch with WebObjects / Project WOnder during > my training. > > Now I would like to convert a node application into a wonder application. And > here I have a question. How do I create a authentication via REST and make my > routes only available for authenticated users? > > Thanks in advance > Gabor Raz > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > This email sent to prob...@macti.ca ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
REST authentication
Hi Guys, I normally make my own projects with Node.js. Most of them with the MEAN.IO framework. But I also came in touch with WebObjects / Project WOnder during my training. Now I would like to convert a node application into a wonder application. And here I have a question. How do I create a authentication via REST and make my routes only available for authenticated users? Thanks in advance Gabor Raz___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST Authentication
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? >>>>
Re: REST Authentication
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 (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>> >>> This email sent to msch...@mdimension.com >> > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/jlmiller%40kahalawai.com > > This email sent to jlmil...@kahalawai.com 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST Authentication
On 19. Mar, 2010, at 18:28 , Kieran Kelleher wrote: > 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? For this I'd rather use an auth token that is encrypted and can be cracked on the server to relate it to an account. You could make that valid for a given time (store it in memcached, file system, db, ... with expiry date) and relate that on the server side to the actual account after the user logged in at least once. As it is a web application, you probably don't want to sent long lived tokens around that could end up in browser caches and the like ... cug ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST Authentication
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 (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >> >> This email sent to msch...@mdimension.com > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST Authentication
If you have access to OpenBase 11, you could try their XML/JSON server, <http://openbase.wikidot.com/connectivity-apis:xml-server>. On 2010-03-19, 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 (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/andre%40geometria.net > > This email sent to an...@geometria.net ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST Authentication
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 (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com > > This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: REST Authentication
I agree that it's a mess. I guess you could even use HTTP Digest and HTTP Basic Auth for authentification. Bit.ly use a username and API key system, but like CampaignMonitor, it's over HTTP so if someone sniff your trafic, you're toast. It look like API keys are the way to go for public-but-not-dangerous- for-your-image services like Bit.ly, and HMAC + HTTPS is the way to go for more secure REST services. 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca This email sent to prob...@macti.ca ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
REST Authentication
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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
