Not to be obtuse, but have you considered embracing this aspect of things?
Since the libraries have to be sold with your apps (right?) it seems to me a saleable feature to also provide useful functionality on top of that. You may then also have the option of just selling updates to the libraries "app-less" to those that have used them. You could probably come up with some type of checksum procedure for the CFCs. Your apps would pass some value into the CFCs which would be validated against some key (basically the way most key-based software protection works). You might implement an encrypted registry key: when one of your apps starts they place an encrypted value in the registry and "register" to use the core components for a certain period of time. The apps could then reregister periodically using new keys (and some secrete method for generating them). However personally I think that anything you do is just going to add complexity (and thus bugs) to the core components and is probably going to be rather easy to circumvent. The simple fact is that there has never been a completely successful software protection scheme. So I'd make a feature of it and sell the toolkit. ;^) Jim Davis > > 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. ---------------------------------------------------------- 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]
