The reality is that if your CFCs are on the server in the first place and your clients have access to that server you'd be hard-pressed to really restrict their access at all.
You could put in logic that checks/parses the getBaseTemplatePath() and aborts if it's not one of the "approved" sites -- though, if you are putting your CFC in the server scope you'd need to do that check for every method. That is ugly, but it could work if you can know the paths to your applications as distinct from their applications and assuming those dev teams won't just edit out those lines of your code.
Barry L Beat tie wrote:
----------------------------------------------------------hi all
we have a number of clients who have copies of our apps on their webservers (one and only - no clusters).
thanx to moving a lot of logic to server-stored CFC's (a bunch of singletons), our multiple apps can access them. We've now (under development) got a common library to call and use, since there's a lot of overlap between apps.
but this means: so do our customers, some of which have their own CF dev teams. We have convienantly created an easy to use API for them too!
any suggestions on how to restrict access of our server-stored service CFC's to only be used in our apps?
thankfully this is still under development so we've got room to move for new ideas.
thanx barry.b
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]
