Preventing end users from using copies of your front end - the solution (1 Viewer)

[medihub_guy]

Good day everyone,

I was thinking of ways to license my front end. Yes I know there are third party solutions, but I think what I did works just as fine.

So here's the deal:

1. I have 2 forms that remain open but hidden whilst access is open (i.e. Splash Screen and my Login Screen)
2. I then have a table in my SQL server that marks if a work station is online.
3. When the database application is opened, the splash screen trigger the onload event that marks the workstation attached to that front end as "OFFLINE" or Online = false.
4. The login screen that is open has a timer interval of 1000 milliseconds where if it is marked "OFFLINE" then it would close all forms and quit the application with a msgbox stating "Only one copy of this application can be opened at a time".
5. The beauty is is that the newly opened front end login screen is not opened yet. But, the person who was logged in all along was shut out of the database unannounced.

I know what you maybe thinking: unethical customers can use the front ends at different times. Well, I would say it depends on the customers you have. I created a pharmacy management application and it wouldnt be practical for my customers to do this as most if not all pharmacies are opened generally at the same time throughout the day.

Has anyone ever taken this approach before? I am eager to hear your feedback.

Medihub guy

 

[theDBguy]

Probably not the exact same approach, but there's generally different ways you can restrict usage. I don't see why you can't allow multiple users at the same time. That's basically what an Access database application is for - to allow multiple users to work with the data at the same time. That doesn't mean you cannot limit the number of concurrent users though.

 

[medihub_guy]

Probably not the exact same approach, but there's generally different ways you can restrict usage. I don't see why you can't allow multiple users at the same time. That's basically what an Access database application is for - to allow multiple users to work with the data at the same time. That doesn't mean you cannot limit the number of concurrent users though.

Hi there DBguy,

The purpose of this is to prevent paid users from sharing the database application with unpaid users.

If you are a paid user you can use the access database application concurrently with other paid users.

I hope I'm making sense here.

Bottom line is I do allow multiple users to use the database application at the same time. Each front end is unique and if a paid user were to try copy that front end accde file and place on another computer and then use concurrently with the other copy, this mechanism kicks in.

 

[The_Doc_Man]

Doesn't stop the case of the pirate using the copy when the legit copy is idle though, does it?

 

[medihub_guy]

Doesn't stop the case of the pirate using the copy when the legit copy is idle though, does it?

No but its hard to imagine someone that would endure that level of inconvenience. To log out of the app then log back in during normal working hours is a bit impractical. Also, I mentioned in the initial post that it also depends on the customer you have. My customers are pharmacies of whom are open generally all day. It would be hard to synchronize down times between both locations to save a few bucks a month.
Not to mention, the company's information must be changed by myself. But essentially you're right and I acknowledge that.
There are ways to police this. I've seen older methods like retrieving the name of the computer and registering it in a table and only have the app recognize that device. But then Ive seen some people get around that by naming the computers the same. Of which is a bad idea but hey people can get desperate I suppose.
I would love for somebody to add their 5 cents to this idea though to see if we can make this bulletproof!

 

[medihub_guy]

I suppose I can create a table to monitor this sort of behavior as well. Every time this mechanism kicks in I can be made aware of it. Perhaps a counter against each customer name? Any advice here?

 

[Josef P.]

How do you register the client shutdown in the SQL server?
Does this also work if the client crashes unexpectedly - or can the user then no longer log in?

 

[medihub_guy]

How do you register the client shutdown in the SQL server?
Does this also work if the client crashes unexpectedly - or can the user then no longer log in?

I can register the shutdown with an sql_insert statement into a table that counts the shut down event, at what date/time and on what computer.

Im not sure I understand your second question. If the client (paid user) crasher unexpectedly then the mechanism doesnt happen. When the client tries to login again and the splash screen opens, all the parameters reset and they can now login normally.

 

[medihub_guy]

Just to add, I also track the number of users currently active if by some chance the "pirates" bypass this.

I also add an sql_update statement to add the number of users that are successful in logging in (when they click the login button on the login screen, this will happen).

Once it's <>1 then the user that is beyond the splash screen in will experience the mechanism.

I'm trying to put a chart together to explain this. Please feel free to critique the heck out of it. You will be doing me a huge favour.

 

[medihub_guy]

Hey guys, take a look at the image attached. I hope it gives you all a better understanding of what I've done. If there are any kinks in my armor, please feel free to call me out on it. I greatly appreciate all your criticism.

 

[MsAccessNL]

I think this should work. I am always a bit scary to use timer code,especially every second. Vba doesn't run asynchronoustly so i wonder if this Doesn't slow down other processes in Access? Do the experts have an educated point about that?

(Don't forget that an experienced developer could get the connection string from you linked tables and this contains the password to the server..)

 

[medihub_guy]

I think this should work. I am always a bit scary to use timer code,especially every second. Vba doesn't run asynchronoustly so i wonder if this Doesn't slow down other processes in Access? Do the experts have an educated point about that?

(Don't forget that an experienced developer could get the connection string from you linked tables and this contains the password to the server..)

MsAccessNL you're absolutely right in regards to slowing down the performance. This is why I increased the interval to every 10 seconds (10,000 milliseconds). I noticed this last night and changed it. It seems to be working fine now. Good eye sir!

Also, I have a few thoughts about developers getting a hold of my code:

First, if they are that experienced then they could have mimicked what I've done anyway. It would just have been a matter of time before they did.

Second, if they get my code so what. The market I chose (pharmacy), I already have an "in". I'm a pharmacist myself . They would have to be a damn good salesman to take my market share.

Indeed, I am worried about malicious acts once they have the keys to my server. Any advice on how to minimize this?

Hopefully more comments roll in and we can make this method bulletproof for others to incorporate to their database applications.

 

[MsAccessNL]

MsAccessNL you're absolutely right in regards to slowing down the performance. This is why I increased the interval to every 10 seconds (10,000 milliseconds). I noticed this last night and changed it. It seems to be working fine now. Good eye sir!

Also, I have a few thoughts about developers getting a hold of my code:

First, if they are that experienced then they could have mimicked what I've done anyway. It would just have been a matter of time before they did.

Second, if they get my code so what. The market I chose (pharmacy), I already have an "in". I'm a pharmacist myself . They would have to be a damn good salesman to take my market share.

Indeed, I am worried about malicious acts once they have the keys to my server. Any advice on how to minimize this?

Hopefully more comments roll in and we can make this method bulletproof for others to incorporate to their database applications.

I fully agree with you and I want to complement you with your design. It looks very slick and modern. Well done!

 

[medihub_guy]

I fully agree with you and I want to complement you with your design. It looks very slick and modern. Well done!

Thank you so very much @MsAccessNL for your kind words! I'm happy you like it!

 

[MsAccessNL]

If you ever get in problems with your timer code, I have been experimenting with checking data from the server with Javascript or PHP. This will run async and i got a way to catch the async return into vba. Php code is especially interesting because this code wil run on the server side and will not intervere with the client code.

 

[medihub_guy]

I will keep that in mind. I don't know much about PHP though. Would be interesting to see how it works.

 

[jacko6]

Not sure if this helps your situation, but to restrict access to my apps I have a licensing table in the shared backend db. This table contains a column that stores the windows name of computers that are licensed.

Whenever the front end is started my login screen is the startup form. VBA code in the load event gets the windows computer name and checks for a matching computer name in the licensing table. If found then the login screen is shown normally with login controls made visible. If not then the login screen displays info about the computer not being licensed and normal login controls remain non-visible.

Works a treat and you can extend the licensing table to suit your needs. For example you may also want to license certain "add-on modules" within your app.

 

[The_Doc_Man]

My next question relates to the environment where this runs. Are you under the control of a formal domain controller that enforces logins? If so, you can look at some of the security ideas of our member Isladogs, who has published LOTS of articles on using domain security to assure who is logged in. You can also ask questions of the domain to assure the computer on which the app is running. Therefore it would be possible to bind a particular system by determining if this is the first run of the app, and by then putting that 'puter in a BE table associated with a login name and other info. Then you could, if needed, have a flag in there that you could set to show that the given combination is an unauthorized use. That would work unless you allowed users to log in from more than one workstation (just one workstation at a time).

If you do not have a formal domain controller, unfortunately that computer ID might not be so easy to assure. One idea on that subject, noted in this forum, is to use the FILESYSTEMOBJECT to get the drive serial number for your system disk. The S/N doesn't change unless someone has a disk failure that requires disk replacement, which in turn would require re-imaging of the disk, so the app would have to be re-downloaded anyway. You could use the disk S/N to identify the particular computer. And if you use FSO, you can tell the difference between a fixed, network, or removable drive, so that would be a way to assure WHICH drive you are examining.

I had a setup where I could see who was logged in via a login history that had TWO date fields - a LOGIN and a LOGOUT time. If I had two LOGIN times without an intervening LOGOUT time, I would know to investigate. If you also included the computer ID and you had two close LOGIN times from different computers without a LOGOUT, you would know that something went wrong and needed investigation.

 

[Edgar_]

I am worried about malicious acts once they have the keys to my server. Any advice on how to minimize this?

Keep your keys out of the frontend. I get that your users are mainly pharmacists and you might not expect them to mess with your frontend. But, if any of them have a computer-savvy friend or family member, there's a chance they'll give it a shot and find a way in.

So I suggest you move your data to a web server that listens for http requests. Here's how it would work:
1. User logs in, sends his credentials
2. If credentials are good, server creates, sends a key, and stores it (expiry date and other data is encrypted in this key)
3. Frontend receives and stores the key from the server to use it in subsequent requests
4. The server analyzes every request made by your pharmacist users by analyzing the key they sent with the request
5. If the key has expired, the server just won't send data
6. If the key is known to be nasty, you can revoke it even if it's not expired, you can detect malicious users automatically
7. If the key is valid, the server sends the data
8. You can program the frontend to shutdown if the server denied access
9. They can still get into the code and attempt to delete that line, but since the validation is done in your server, there's nothing they can do even if they can see how the frontends try to communicate with the server, they can see the encrypted too, but there's not much they can do because, well, it's encrypted

 

[Pat Hartman]

I don't understand why your application is restricting the users to 1. Do you distribute separate copies of the FE for each user so that multiple people can actually use the application at the same time; they just can't copy another FE to do it? Do they then share the same BE?