rdemyan via AccessMonster.com wrote:
I'm trying to implement a licensing scheme. There are three types of
licenses:
Trial - good for 30 to 60 days
Interim - good for 1 year
Fully Paid - no expiration
Everything is working fine and I've even implemented a registration system
where the users can upgrade by just receiving a code from me.
My question is on where should I store the license information. I'm
concerned about a couple of things:
1) If I store the info in a front-end table, I can access it immediately
prior to my backend linking routine. BUT, what happens when a new version
of the app is released. This info in the front-end will be lost for each
client and I would have to recreate it for each client before shipping out
the app.
2) If stored in a backend table, I'll have to link to the tables before
checking the license info. My backend is locked down so no one except me can
get into it. So this might work okay.
3) But if the info is in a table, what happens if somehow it is lost or that
particular table gets corrupted. Users with fully-paid licenses might get
upset, because they won't be able to get in.
I guess I could have a hidden form that loads on startup and would
permanently store the license information. But this would require that the
registration routine (when users upgrade) open this hidden form in design
mode and write the license information, wouldn't it??
I'd like some suggestions on how experienced developers would or do handle
the storing of license information. Also, if there are any "failsafe"
mechanisms in case there is a problem retrieving license information.
One note: These clients do not allow the downloading or installation of
executables and we cannot touch the registry.
Thanks in advance.
Many years ago, when I first started working with computers, I was a
computer operator. I had access to Master Control. This was a DG
computer. There were 2 levels higher than Master Control when it came
to computer security. The computer operators at the company got into
competive games, sending ClearScreen signals to the other ops, locking
them out of the computer even if they had Supervisory privileges. One
day the games got a little hot and I decided to make one of my opponents
pay dearly. The program to change security permission was called
Predator. I renamed Predator to something else and buried it down a
folder path about 15 levels deep. Then I locked out my opponent to user
level. She laughed at my weak attempt to lock her out. She immediately
tried to activate Preditor...file not found. What? She tried to login
as supervisor. Locked out. What? She went to the master control
terminals. Locked out. So she went crying to the manager, tears
streaming down her face. I had defeated her. After a chewing out, and
my humble apolgies (while secretly gloating), I restored Predator and
unlocked the operator.
So what does this story have to do with your situation? My suggestion
is that you hide your key. I wrote a program a few years ago in Access
to hide the key if I ever wanted to limit a program to a time period. I
own the code to create the key. Even if someone somehow got the code to
unlock my key, which would be supplied in the application, it wouldn't
help much. If they modified it to up their time length, since they
don't know what the real key is, they'd lock out themselves even further.
Where I hide the key is my business. You can find your own hideaway. I
will tell you that I do hide it in a file. When I write the file, I
first get the date created/viewed/modified of the file, modify the file
in such a way that the files length does not change, and when I write it
back, I then update it to the original times. My belief is that the
user, confronted with a file with the same times and length, will
consider the file unchanged. Even if the person knew the file I hid the
unlock key in, they wouldn't know where it is because the key is
scattered throughout the file.
Now if someone gets my code somehow for unlocking the key in the file,
as I said earlier, the method/code that actually creates the key will
never be provided in my database. And without that code, about all the
user can do is spend a hell of a long, long time trying millions of
computations to break it. Most people don't have the patience to try/do
that.
I'm sure there are many other ways to do this...setting up a licensing
scheme. Whether or not you want to get elaborate or not depends upon you.
