I've been told that plotting works best in dark places - and assuming the usual lurk to post ratio, I don't think the list would qualify :->
I *will* recommend anyone who hasn't done so already to SIGN UP for FAQU: http://www.fusionauthority.com/quarterly/ It really is excellent quality. Judith and Dee do a great job of making authors argue their positions and make their content intelligible (unlike the painfully bad stuff that CFDJ used to let through). These just isn't a better resource out there. I get sent a free copy of every issue as I've written an article in all of them (except for the very first issue), but I still subscribe as without our support, people aren't going to continue to create these resources. Also, it's priced in US Dollars, so take advantage of the good exchange rate and consider this a 30% discount off what the price would have been a while back with the stronger dollar! https://secure.houseoffusion.com/ Best Wishes, Peter On 12/13/07 5:15 AM, "Barry Beattie" <[EMAIL PROTECTED]> wrote: > > LOL! you're ahead of your time, obvoiusly! > > this list could always (unofficially) prood read the article for > you... we won't tell anyone - honest! > > On Dec 13, 2007 7:40 PM, Peter Bell <[EMAIL PROTECTED]> wrote: >> >> 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 -~----------~----~----~----~------~----~------~--~---
