I'm interested in seeing how you maintain a session through web services. -adam
> -----Original Message----- > From: John Temm [mailto:[EMAIL PROTECTED] > Sent: Monday, March 29, 2004 01:59 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Role based Security > > Hi Sean, > Why would you need to prevent CFCs from being instantiated by other than authorized > users? Couldn't you simply apply Roles to the methods of the CFC, thus preventing > unauthorized users actually making the instance DO anything? Have you come up with a > parallel approach? > > I ask this because I have made extensive use of roles and am starting to worry about > its impact on my ability to efficiently expose CFC webservices. Brandon Purcell > posted a response to an earlier query of mine on the topic and made available some > excellent work he has done on using various methods of authentication and session > management (for remoting, webservices, etc) @ > http://www.bpurcell.org/blog/index.cfm?mode=entry&ENTRY=978 > > My use of roles makes for a very fine-grained functional security model, but if it > is going to make my life harder when I want to use these classes outside of CF (via > webservices or remoting), I need to start thinking hard about how to move forward. > The previous post and Brandon's response can be found here > http://www.mail-archive.com/[EMAIL PROTECTED]/msg03624.html > > Anyone else have anything to add to this? My specific concern would be calling > role-secured CFC methods from Flash through either remoting or webservices and > maintaining session state across multiple calls. Essentially, floating a flash app > on top of a CFC backend that relies on roles to secure most methods. > > Cheers, > Chip Temm > Dir Knowledge Architecture > Conservation International > Washington, DC, USA > +1 202 912 1402 > > > -----Original Message------------------------------------------------------------ > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sean A Corfield > Sent: 27 March 2004 19:31 > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] documentation concern > > > On Mar 27, 2004, at 12:46 PM, Nathan Dintenfass wrote: > > So, are people just not running into this because they don't do any > > external > > "work" in their pseudo-constructors? Are they just accepting that > > it's a > > fact of life? Are they unaware of the potential for badness? Is > > there a > > work-around I'm unaware of? > > We have a couple of CFCs that cannot be viewed through the cfcexplorer > because of work they do in the pseudo-constructor but they are the > exception (they do security-related things to prevent the CFCs being > instantiated except by authorized users - they're part of our > membership subsystem which is very tightly locked document). We are > generally very careful to do nothing beyond simple instance variable > initialization in the pseudo-constructor. > > Regards, > Sean > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
