Hi Duncan, I just treat it as another parameter, and actually I avoid SOAP for me simple XML with a RESTful interface is ³the simplest thing that works². I get that some places mandate SOAP, but my experience with Java/.NET SOAP interop has been that sometimes you just get weird errors, and for me SOAP isn¹t bringing that much to the party. If you can, consider just a simple http get or post (URL paramaters or form fields easy for any web programmer to do) that calls your page which just returns simple XML. I understand there are plenty of times you can¹t get away with that, but hard to beat the simplicity of that approach if you¹re able to do it . . .
Glad you enjoyed the preso! Best Wishes, Peter On 12/13/07 6:32 AM, "Duncan" <[EMAIL PROTECTED]> wrote: > Thanks Peter, thats the kind of approach we have used before, its always nice > to get a sanity check. > > Would you pass it through in the SOAP header or just as another param in the > body? > > Thanks for coming to cfcamp too, enjoyed your preso in Sydney > > Duncan > > On Dec 13, 2007 9:15 PM, 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] >>> <mailto:[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 -~----------~----~----~----~------~----~------~--~---
