thankyou people. sounds like the options are:
1) give up. Sell the idea as a feature (cute marketing, Jim!) and live with others accessing the objects 2) instanciate in application scope instead but all apps point to the same CFC codebase. Don't bother sharing any CFC instance data across applications (not a big deal). this probably won't help much but at least we'd have a bit more control. 3) since all methods have to pass in a "CompanyCode" (dependant on the users login) encrypt it on the calling page and decrypt on the called CFC's. since the cfm files are themselves encrypted, it'll take them a while to suss out why their (foreign) companyCode values won't work. But as Spike said - diminishing returns (security by obscurity) I only hope these CF developers who work for our customers aren't on this list! cheers barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- 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]
