I have extensively used roles with Flash Remoting and have had no problems. In fact, using the roles attribute is the best way to ensure that your remote methods are being called by an authorized user (from Flash... for publically consumable web services, I'm not sure. You might want to set up a facade for this anyways).
-dave >>> [EMAIL PROTECTED] 3/29/2004 8:59:49 AM >>> 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]
