Well, I wrote an article for the upcoming FAQU on this very topic if that helps . . . I'll try to get a blog post up, but don't want to beat my own article to the punch!
Best Wishes, Peter On 12/13/07 1:52 AM, "Barry Beattie" <[EMAIL PROTECTED]> wrote: > > Peter, > > you wouldn't happen to have a blog entry or two (or recommend such) > on this, would y' now? by chance, perhaps? > > > > > > On Dec 13, 2007 4:41 PM, Peter Bell <[EMAIL PROTECTED]> wrote: >> >> We use a taken based approach. +1 for password with every request not being >> an ideal approach, and you've got to look out for sessions with web >> services. I'm not sure that they will be available. As for cookies, we >> decided it'd be easier for us (and our partners) to just pass a parameter >> explicitly rather than to have to write the code to work with cookies. >> >> Our general approach is: >> - Client calls authenticate method authenticate(User, Pass) >> - Method returns either a token or an error code based on API >> - Client calls any other method, one of the required parameters is the >> token >> - All methods validate the token and either return an appropriate error >> code (invalid, expired, malformed, etc) as per API or go ahead and return >> the expected value. >> >> Best Wishes, >> Peter >> >> >> >> >> >> On 12/13/07 12:51 AM, "Zac Spitzer" <[EMAIL PROTECTED]> wrote: >> >> >> >> passing the password in every request just feels bad, everything else aside >> >> tokens work well in my experience, cookies and tokens are pretty much the >> same idea >> slightly differently executed... >> >> i think in terms of interoperability tokens are the best >> >> z >> >> On Dec 13, 2007 4:39 PM, Duncan <[EMAIL PROTECTED]> wrote: >> >> Hi all, >> >> We are just embarking on a WebServices project and I would like some >> opinion on the best way to run authentication for it. >> >> I am looking for opinion on each of the following methods with regards to >> the ease it takes to integrate to it from another language or CF. We could >> have .NET, Java etc connecting to it so we need something that is secure, >> but still straight forward for others to integrate with quickly. >> >> As far as I know there would be 3 ways to handle the authentication on a >> high level, Cookie/session, custom token, auth on every request. I have done >> this before, but never sought opinion from the outside world. >> >> My thoughts are as follows: >> >> - Cookies: can be used to save data provided by CF to refer back to session >> or client variables just the same way as a browser session. OK, but I >> understand that the cookie values would be written into the SOAP header. >> This would also involve extra programming on the consumer side. >> Pro: CF handles timeouts etc simply via the application.cfc, only login >> once >> Con: extra coding for consumer to turn around headers each request >> >> - Custom token >> Pro: only lookup user once >> Con: token changes on each request to update timestamp. Custom code to work >> out timeouts and if still logged in etc. >> >> - Pass username / password on each request: >> Pro: no persistent data, no complications of passing specific variables >> back and forth >> Con: have to pass probably more data than required, more processing than >> required as will have to look up user on every request. >> >> 1) Do any of these require more work for, say, a Java or .NET developer to >> consume than another one? >> 2) Is passing the usr/pwd on every request considered unsecure? (This will >> run over SSL exclusively). >> 3) Is there best practice in the CF world for this? If so is it one of >> these methods or something I missed? >> >> Thanks all! >> >> >>> >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~----------~----~----~----~------~----~------~--~---
