Expiring Passwords

[Allegheny]

How can I cause a password to expire 1 month after initial use of my runtime solution? Since this solution will be downloaded by different customers at different times, I can't set the expiration date to be the same for all users.

Ideally I could establish many passwords. The first password would allow the user to run the solution for days 1-30, the second for days 31-60, etc. Users would have to purchase the new password each month, having been prompted by the solution to remit payment. Perhaps a startup screen could indicate the number of days before the password would expire. At the end of the purchased use the file would lock out the user and nullify the previous password.

Anybody used this tactic before?

[LiveOak]

The easiest way would be to create your own password system and use FM passwords only to protect this system. Then you could perform whatever tests you wished. Since FM Runtime is single user, you can use hidden globals as flags to keep track of where your are in the 30 authorizations. Removing the database structure would provide additional protection from attacks using FM to open the files.

-bd

[Allegheny]

Using globals sounds good, but how can we keep tally of days rather than uses?

[Vaughan]

Distribute the solution with an empty global field. make a startp script that neters the current date only f the field is empty -- this will be the date of first running. Script in a message and quit if the start date is whatever days before the current date.

[Allegheny]

You bring up a good point about entering the current date only if the global field is empty. That very thing has been stumping me for ages. How do I force the solution to perform an action if the field is empty?

Will I need multiple globals to match the current date with the date that was entered in the global field upon first use? How do I write the script to compare current date with first-use date

How do I disallow use of the solution (or force quit) if 30 days have passed?

Thanks for being more specific. We've been scratching our heads about this one.

[Vaughan]

Make a startup script:

if the global date field is empty

set to current date

if global date field < (current date - 30)

Show message "Sorry 30 day trial has expired."

Quit.

What's hard about that?

[Hint: use the IsEmpty() function to check if a field is empty.]

[Allegheny]

Funny thing about your suggestion, Vaughan, it nearly locked me out of my solution. If I were a complete novice, I would have been really screwed. Here's how I constructed my startup script:

if [isEmpty(global date), Today, " ")"]

Else

if [global date< (Today-1), "Your 1 day free trial has expired. Call us to purchase a membership.", " ")"

end if

End if

Close application

Quit

I see my error is not including the "quit" in the if statement, but I'm not sure how to fix it. Suggestions?

[Vaughan]

quote:

---

Funny thing about your suggestion, Vaughan, it nearly locked me out of my solution. If I were a complete novice, I would have been really screwed.

---

*Nearly* locked you out... hmmm not good enough! My apologies, I should have tried harder! However, it's a good lesson: backup, backup, backup especially before putting in scripts that have the potential to lock the solution.

Mind you, that script can't lock you out. It's too simple, it was only intended to be an example, a starting point. If you think a few minutes about how it works you'll be able to crack it really easily.

For instance, setting the clock back in time before the install date will let the user back in again after it expires. Alternatively, if the user sets their clock forward 10 years before first running the database then sets the clock back to normal, the script will allow it to run for 10 years + 1 day.

A "complete solution" would include a "back door" for the administrator and be much, much tighter with checks for all the above scenarios. Something thorough with all the bells and whistles -- and the bugs worked out -- would probably be a couple of days work.

BTW forget the Today function. Today only re-calculates when the file is first opened, so if it's on a server that's constantly open it will not give the value expected. Use Status(CurrentDate) instead.

[Allegheny]

I still want to establish an expiring password system, but by counting the number of times the file has been opened. That would prevent the need for customers from changing their system dates to counteract our "membership ends in 30 days" policy.

Is there any way to keep track of the number of times a file has been opened?

[Ocean West]

On startup set a global field to itself minus 1 initially send it out set with 25 or 30 uses. Then do a test to see what the count field is if it is < 1 then pop the message that they need to call you to license a copy from you.

You could have on the front screen a message "You have XX uses left."

[Allegheny]

I don't quite understand what you mean. Please be a little more sequential in your explanation.

What function do I use to trigger a global field to keep count of the number of openings? Is this just a matter of accessing the global field only upon startup and therefore only "adding 1" with each startup? It feels like I'm getting close, but not close enough.

[ November 07, 2001: Message edited by: Allegheny ]

[Vaughan]

One way of doing it: a global field in the database "countfield" is the run counter. This countfield field needs to initially be set to the number of runs the trial is limited to (say 30). Make this script and set it to run at startup:

Allow User Abort [off]

Set Field [countfield, countfield - 1]

If [countfield < 0]

Show Message [Trial has expired.]

Quit Application

End If

Note that this isn't the final solution, there needs to be more work done to set the initial value of the countfield, admin backdoor put in, bugs worked out, etc. Backup the database before using. No warranties expressed or implied, use at your own risk. It will lock you out after 30 runs, though it can be worked-around by opening the file through an external script (to avoid triggering the startup script) so it's not water-tight.