I'll try to put one together this evening and run a few tests to see how
it goes.

Spike

> -----Original Message-----
> From: Douglas Humphris [mailto:[EMAIL PROTECTED]] 
> Sent: 05 September 2002 13:15
> To: [EMAIL PROTECTED]
> Subject: RE: [ cf-dev ] .cfm enryption
> 
> 
> Yeah, run the component from a seperate server so that they 
> can't touch it. I'd be interested to know what effect this 
> would have on performance because this is a genuine solution 
> I was thinking about the other day...I guess the only way is 
> to run a few tests.
> 
> Would anyone like to set up a test CFCOMPONENT as a 
> webservice that I could run from here, and then compare the 
> time with invoking it on the same server?
> 
> Cheers,
> Douglas
> 
> --
> Douglas Humphris, Programmer
> http://www.unitech.net
> 
> -----Original Message-----
> From: Spike [mailto:[EMAIL PROTECTED]]
> Sent: 05 September 2002 12:07
> To: [EMAIL PROTECTED]
> Subject: RE: [ cf-dev ] .cfm enryption
> 
> 
> That's an interesting suggestion...
> 
> How would you stop the nasty evil code thief from rewriting 
> the component so that it skipped the DB check for the 
> registration key?
> 
> Or were you suggesting that the component should reside on a 
> separate server not controlled by the client?
> 
> If so, then you're probably going to run into some 
> performance issues. Having said that, I think it's exactly 
> the way it should be done (performance aside), and is a major 
> feature of webservices.
> 
> Spike
> 
> > -----Original Message-----
> > From: Douglas Humphris [mailto:[EMAIL PROTECTED]]
> > Sent: 05 September 2002 12:55
> > To: [EMAIL PROTECTED]
> > Subject: RE: [ cf-dev ] .cfm enryption
> > 
> > 
> > With CFMX, you could write key parts of your app as
> > CFCOMPONENTS and deploy them as webservices. Program your app 
> > to depend on running the components in order to work. For 
> > each component, have a required argument which takes a 
> > registration key. The first thing each component does is 
> > check your db that the registration key provided matches the 
> > registered IP/domain - if not email yourself, and return a 
> > warning message.
> > 
> > Then to completely freak them out, phone them up as soon as
> > the email comes in and tell them your solicitor will be in touch...
> > 
> > Douglas
> > 
> > --
> > Douglas Humphris, Programmer
> > http://www.unitech.net
> > 
> > 
> > -----Original Message-----
> > From: Spike [mailto:[EMAIL PROTECTED]]
> > Sent: 05 September 2002 11:39
> > To: [EMAIL PROTECTED]
> > Subject: RE: [ cf-dev ] .cfm enryption
> > 
> > 
> > It is perfectly possible to decrypt .cfm templates encrypted
> > with all versions of cfencode. This includes CF5 and CFMX.
> > 
> > If you are using CFMX there are several things you could do
> > to protect your IP.
> > 
> > 1. Ensure that the client signs a contract that puts them in
> > legal hot water if they as much as look at even the encrypted 
> > templates. (This is mostly a deterrent, but it does give you 
> > legal grounds to go after any
> > abusers)
> > 
> > 2. Put legal notices in the templates that make it clear that
> > by reading the notices they have broken the terms of their 
> > contract and that they should immediately delete the 
> > decrypted template. Some other well worded stuff on the legal 
> > implications of decrypting the template wouldn't go amiss 
> > either. (Again, this provides a deterrent and some more legal 
> > back-up. They may not have read or be aware of the contract 
> > that was signed, so putting the information in each templates 
> > makes sure that they know they should not be doing what they 
> > are doing.)
> > 
> > 3. If you are using CFMX you can (in theory at least) deploy
> > the class files for the application without the CFM templates 
> > themselves. That would be totally unsupported by MM, and 
> > would probably break as soon as a service pack or what-ever 
> > was applied to the server, but if you're really paranoid 
> > about your cfm templates being stolen it's worth investigating.
> > 
> > 4. Create a COM Object, CFX tag, or similar external system
> > on which your code heavily relies. Make sure that this will 
> > only work on one server. There are lots of ways you could go 
> > about this, but none of them are really simple and most are 
> > prone to the same sort of problems that you would get with 
> > deploying the app with class files only.
> > 
> > 5. Write your code in such a way that no-one except you can
> > understand it. This is actually a lot harder than it sounds 
> > if you've been programming for a long time, and it makes it a 
> > nightmare to debug and maintain.
> > 
> > In general, unless you've come up with a killer app of some
> > sort it's probably only worth going to the legal contract and 
> > warning notices route, as the potential hassle involved with 
> > the other solutions isn't worth the gain.
> > 
> > Spike
> > 
> > > -----Original Message-----
> > > From: Garry Mills [mailto:[EMAIL PROTECTED]]
> > > Sent: 05 September 2002 11:31
> > > To: '[EMAIL PROTECTED]'
> > > Subject: RE: [ cf-dev ] .cfm enryption
> > > 
> > > 
> > > > btw I don't think cfdecrypt can decrypt cf5 files, although
> > > looking at
> > > > the shrewm notice board, there seem to be people 
> claiming they can 
> > > > (for a
> > > fee).
> > > 
> > > Interesting, anybody tried it with MX?
> > > 
> > > Garry
> > > 
> > > > -----Original Message-----
> > > > From: Garry Mills [mailto:[EMAIL PROTECTED]]
> > > > Sent: 05 September 2002 10:10
> > > > To: '[EMAIL PROTECTED]'
> > > > Subject: [ cf-dev ] .cfm enryption
> > > > 
> > > > 
> > > > We're rolling out a product to a customer soon, and
> > bluntly speaking
> > > > we don't want them to be able to copy the app onto 
> another server.
> > > > 
> > > > Know about cfencrypt, and also know about cfdecrypt and 
> whilst it
> > > > will stop the numpties getting into it doubt the tech 
> department 
> > > > will
> > > find it as
> > > > difficult
> > > > 
> > > > A google search for coldfusion dongle returns a load of
> > > links to crack
> > > > files...
> > > > 
> > > > What do the rest of you do, or is cfentrpt our only
> > option? (oh, and
> > > > I tried CF encrypted files on a Cobalt once and it 
> didn't seem to 
> > > > work, although thats a separate issue)
> > > > 
> > > > Garry
> > > > 
> > > > --
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: 
> [EMAIL PROTECTED]
> > > > For human help, e-mail: [EMAIL PROTECTED]
> > > > 
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED] 
> > > For human help, e-mail: [EMAIL PROTECTED]
> > > 
> > > 
> > > --
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED] 
> > > For human help, e-mail: [EMAIL PROTECTED]
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: 
> > [EMAIL PROTECTED] For human help, e-mail: 
> > [EMAIL PROTECTED]
> > 
> > 
> > 
> > --
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: 
> > [EMAIL PROTECTED] For human help, e-mail: 
> > [EMAIL PROTECTED]
> > 
> > 
> > 
> 
> 
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: 
> [EMAIL PROTECTED] For human help, e-mail: 
> [EMAIL PROTECTED]
> 
> 
> 
> -- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: 
> [EMAIL PROTECTED] For human help, e-mail: 
> [EMAIL PROTECTED]
> 
> 
> 



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For human help, e-mail: [EMAIL PROTECTED]


Reply via email to