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 -~----------~----~----~----~------~----~------~--~---
