Why would you need to prevent CFCs from being instantiated by other than authorized users?
If unauthorized users can't instantiate the CFC, they can't figure out what methods it has - which makes it harder to hack.
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?
We do that *as well*...
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.
That works just fine - as Dave Ross indicated - and it is indeed how our RIAs work on macromedia.com. Our membership components are just particularly sensitive so client applications themselves have to "login" in order to access the membership framework - an extra layer of security.
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]
