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!
I'd say this is a contractural matter and not a coding matter. No
client is going to knowlingly use code they are not contracturally
entitled too especially if the terms of your service are clear. And if some over zealous developer does so, a polite letter to the client will put them in line.
Enforcing the contract is easy: just periodically scan the file system for calls to the relevant server-scope objects. If they are using services they are not entitled to send a friendly letter with a suggestion that they pay for the service or discontinue using it.
If they fail to adhere to the terms and conditions of your service.. terminate their account.
-- geoff
http://www.daemon.com.au/
----------------------------------------------------------
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]
