Licensing My App

[MIKE LYON]

With the help of Barry Rochford's Licensing system idea found on LearnAlpha.com, I have been setting up the system (can't seem to get it working just yet but anyway) and a thought occured to me (easy).

After spending time on setting up the mathmatics, encryption etc to secure it so no 7 yr olds could break it I realised that the whole thing was based around windows date to test if license expired.(oops) All they have to do is change the date!!!!!
As most licensing systems would use a date to test when license expires how do you get around this - is there another
system date that can be used which is secure or what??

Thanks in advance for any input.

[Stephen Williams]

RE: Licensing My App

I dunno, bury it inside a random text string of numbers of loooong proportions, and don't let on which digits are the date?

25432640065435445554956186198718798189107189715464254654654654045454654654045436465414654545

When you do your registration use this date as part of the code they need to get an unlock code from you in the first place. If they mess with it, they need to get the registration date and their registration number right.

I am sure there is a method in here...

[martinwcole]

RE: Licensing My App

A method I use to detect if a user has back set the date or time, to enter financial transactions for earlier dates or times:

The "dummy" table, that the Master Menu is based on, (and the Master Menu is never closed,) has fields containing the last date and seconds past midnight any critical files were written to - either entered or changed.

When the app is loaded, and/or when any of these critical files are entered/changed, I check the current date/seconds past midnight, and if the "current" date/time is less than the "last stored" date/time - they have to have a password to continue, the event is logged, and the user is warned of the event.

[MIKE LYON]

RE: Licensing My App

Martin,
Clever idea but how do I do that, any chance of a simple sample of the way to go about it.

Also wouldnt they still be able to reload the app from scratch each time there license runs out??

Regards
Mike

[martinwcole]

RE: Licensing My App

Yes - they could reload the app - but they would destroy all their data in doing so. Otherwise, if the data were still there, they would still get the message. Another option, which I am beginning to like, is that when the app is initially installed, they would be required to call you and get an activation number, giving you the serial number you had assigned to the app. Then you would know if they were up to no good.

But as to how I manage what I had described, I find the easiest way to do it is (1) at start up, and (2) in field rules for critical files.

At startup, I say something like this in the beginning form's oninitialize event:
'based on a file called dummy
x=toseconds(time()) 'seconds past midnight
y=date()
'the Master Menu has two hidden field objects-datelastupdated and timelastupdated from the dummy file

if parentform:datelastupdated.value > y
ui_msg_box("Error!!!!!!!!!","The computer's date has been changed - all entries will be double logged")
'etc etc put more code here
end if
if parentform:datelastupdated.value=y .and. parentform:timelastupdated.value > x
ui_msg_box("Error!!!!!!!!!","The computer's time has been changed - all entries will be double logged")
'etc etc put more code here
end if
parentform:timelastupdated.value=toseconds(time())
parentform:datelastupdated.value=date()
parentform.commit()

'this takes care of startup

now with, for example, the file "payments", in field rules,
there are a number of things you can do. (1) update the time/date entered/changed, (2) add to an Activity Log, and (3) check to see if they have changed the date/time after they opened the app:

'(3) at the cansaverecord event:
x=toseconds(time()) 'seconds past midnight
y=date()
if y status
log.dated=date()
log.timeentered=dtoc(date()) + " - " + time("0h:0m:0s-AM",now())
log.enter_end(.t.)
log.close()

hope this gives you an idea - you will want to make your own files and include your own fields, but this will at least give you an idea.

putting the code in field rules lets you have the user access the "payments" file from a dozen different forms, but the code only has to be put in one place

[MIKE LYON]

RE: Licensing My App

Martin,

Thank you for all the help, I will give it a try and let you know how I got on.

Regards

Mike

[John Walsh]

RE: Licensing My App

Mike,

You might also consider a counter. Create a single field either in an existing table or in a new table (with only one record). Each time the app starts you run a script that adds one number to the count. You could even have a pop-up box that reads "X number more trial sessions left before program expires". You also need a script attached to the form that loads at startup to test for the value. Have another pop-up box at expiration with info on how to register the program.

[Geoffrey Hollander]

RE: Licensing My App

John,

Sounds like a good solution to a tricky problem. I hate to disable features in a demo. I'd rather set a time limit, but how do you "upgrade" a user upon registration?

I've always wished that it was possible(?) to write a script that could re-write another it when the user registers.

It seems to me that any savvy user could start looking through the tables and change any data that looked like it limited the program or the length of time it can be used.

Best regards,

Geoff Hollander

[Stephen Williams]

RE: Licensing My App

Geoff -
I created a registration function keyed off the company name. The key is kept openly in a table. If the key is "DEMO" they are restricted in the number of records they can add to a table. The function is called with the company name and returns true if registered. So I have not really restricted features, just the volume of work. These registrations are only as secure as the A5 password system.

I think a date is harder to key in, but should be possible. I mean, one could simply hard code an end date, say 60 days from now, and when it crashes send a patch with a new hard coded end date until they register fully. Regardless, if someone wants to change their system date, they will bypass it.

I look forward to learning what new security tools are supplied with version 5 as I think the whole data security issue is a weakness in the viability of version 4 as a platform for commercial work.

[John Walsh]

RE: Licensing My App

Dear Geoff,

What I would do is create a table that contains a field for the counter, a logical field to disable the counter and a field for a registration key. There will be only one record and the table will be hidden from the user. A script is included in the autoexec.bat script. It first looks at the logical field (set to false initially). If it is true (which will be set upon registration), then you goto the part of the script that allows the app to run as normal. If false, then it checks the value in the counter field. If that is 1 (again this is the initial value) then it writes a value to the registration field based on a formula. For example, you could make a key that is equal to the two times today's date (i.e. val(remspecial(dtoc(System->Date)))*2). The next line of the script calls the message box advising how many times left to try the program and a button to register (with a phone number to call you, etc.). When the button is pushed a pop-up box with the registration field is displayed along with a variable field to enter the registraion number. This number is derived by adding together the registration key (see example above) plus a number your company holds, for example "4979". When the customer calls you to register you ask for the key number displayed. You add to that number your "secret" number (i.e. 4979). Of course you don't tell the customer what your doing. You just give him/her the resulting number to enter in the variable field. They then press a button on the form which tests that variable aginst a formula in the script (i.e. val(remspecial(dtoc(System->Date)))*2 + 4979). If they match (as they will if they registered) the logical field is changed to "true" and thus ensuing opening of the app bypasses the count test. If they had not registered, then the counter would be updated by adding one. If at the onset the counter exceeds a predefined amount the app will not run past the registration pop-up box. The advantage of this method is that each registration number will be different based upon the day the application is first run but the user would not likely know how that number was derived or how the PIN allows activation of the app. BTW, I don't write apps for distribution so I don't have a script to give you but this scheme is similar to what some companies use for validation. Hope it leads you to something productive.

[John Walsh]

RE: Licensing My App

The part "...They then press a button on the form which tests that variable aginst a formula in the script (i.e. val(remspecial(dtoc(System->Date)))*2 + 4979). " should be (table->registration_key + 4979)

[Geoffrey Hollander]

RE: Licensing My App

Steven and John,

Thanks for the advice. I'll give it a try and let you know.

Best regards,

Geoff Hollander

[Geoffrey Hollander]

RE: Licensing My App

OOops, Sorry: Stephen.

Geoff hollander

[John Walsh]

RE: Licensing My App

Attached is a little sample app that better examplifies what I mean. Instead of using a static "PIN" howver, I use a mathimatical formula to form the registration key.