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

[medihub_guy]

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?

Hi Pat!

So every license paid comes with one "unique front end accde file". All paid subscribers can use the application simultaneously. The only time a restriction takes place is when an unpaid user tries to use a copy of a unique front end accde file.
So, let's say I have 10 paid subscribers, each one gets one front end file that is unique to their business. If they want more licenses in their organization, they can pay for another unique front end.

 

[Pat Hartman]

That is what I assumed. I was just trying to clarify since the method is unusual. It would make distributing updates to the FE difficult since you have to create multiple separate copies to distribute updates.

Do they share the same BE or is the BE not separate at all? You said this was for a pharmacy but not what function the app performs.

 

[medihub_guy]

That is what I assumed. I was just trying to clarify since the method is unusual. It would make distributing updates to the FE difficult since you have to create multiple separate copies to distribute updates.

Do they share the same BE or is the BE not separate at all? You said this was for a pharmacy but not what function the app performs.

They all share the same BE. Queries with unique IDs keep financial data private. The reason for this is pharmacy management software is pushing towards interoperability. For example right now refill transfers is a manual process (in the Bahamas at least). Having pharmacies on the same database allows us to automate processes like this. It also allows for patient data to be shared once the patient selects their preferred pharmacy in a phone app that is currently being developed. The app will tap into my backend table for the patients allowing them to select which pharmacy they authorize to view their profile.
Also, not all pharmacies are the same so once i don't compromise the integrity of the application, I facilitate tailored changes for my customers. This forces this model.

 

[Pat Hartman]

Your method solves the problem of multiple users within the same network. I presume they wouldn't be sharing the software with competing pharmacies but if you have chains (multiple outlets owned by the same company), then they could buy 10 licenses and use each of the 10 at their 5 separate locations and you could not detect that.

The solution to that problem is what an earlier poster suggested which is a web site which each spp contacts each time it is opened and that confirms the registration of the app. The BE for the app can still be LAN based rather than cloud based. The db in the cloud is simply used to confirm valid installations.

Then once you go to a web verification, you don't actually need separate FE's for each seat. This will become a problem with a widely distributed app which I'm sure you hope this will become.

There are companies that provide this type of web service. I've looked at several but so far none have been suitable for my situation. Your contract with the buyer must also specifically state that the software will "phone home" to ensure that the action is not somehow blocked by the users IT network.

 

[medihub_guy]

Your method solves the problem of multiple users within the same network. I presume they wouldn't be sharing the software with competing pharmacies but if you have chains (multiple outlets owned by the same company), then they could buy 10 licenses and use each of the 10 at their 5 separate locations and you could not detect that.

The solution to that problem is what an earlier poster suggested which is a web site which each spp contacts each time it is opened and that confirms the registration of the app. The BE for the app can still be LAN based rather than cloud based. The db in the cloud is simply used to confirm valid installations.

Then once you go to a web verification, you don't actually need separate FE's for each seat. This will become a problem with a widely distributed app which I'm sure you hope this will become.

There are companies that provide this type of web service. I've looked at several but so far none have been suitable for my situation. Your contract with the buyer must also specifically state that the software will "phone home" to ensure that the action is not somehow blocked by the users IT network.

I'm really appreciating your insight on this. So I have 3 tables describing a company.

1. Site_T: this is the main company's name e.g. Walgreens Pharmacy

2. Location_T: this is the branch name e.g Walgreens Pharmacy - Universitt Drive, Ft Lauderdale Florida 33314

3. SiteWorkStation_T: this is a designated computer within the location that has the unique front end installed. E.g. Walgreens Pharmacy University Drive, Ft Lauderdale FL 33314 - Computer #1

Now I have a Systemdefault_T that includes these 3 fields. These fields together make up the unique number for each work station. No 2 front ends will have the same sequence of numbers.
I do not allow for these numbers to be manipulated. Only I can set them.
All the queries have the location field as a marker to filter information done at that location.
Now the mechanism I have set (please see flowchart in earlier post), once the 2 of the same copies of the unique front end are active or "online", the user that was signed in first front end will shut down. Then the other who signed in second can proceed to.sign in. This, I think, will discourage copying the front end file as it is inconvenient to be sharing a front end with another location as they cannot use it simultaneously. Furthermore, the store information like street address, telephone number etc cannot be manipulated by the end user.
I really hope I'm not wrong here. Do you still forsee an issue with this?

 

[Pat Hartman]

How, exactly, do you identify the site, the location, and the workstation?

The workstation is easy enough. You can use the hard drive ID but what are you using for the other two?

And again, I remind you that I do not like this method even a little bit. I strongly suggest that you either develop your own web app to confirm the licenses or use one of the services that do this.

One of our members - @UncleGizmo is practicing using chatGP and asked this question a couple of months ago and got an answer. Try one of these to see if the tool suits you. If your product takes off, you realllllllllly do not want to be providing customized FE's for each workstation.

Is there a web service that will validate and supply license keys for as fee

Yes, there are several web services available that provide license key validation and generation for a fee. These services are often used by software developers and companies to manage the licensing and activation of their applications. Here are a few examples:

Keygen: Keygen is a popular web service that offers a comprehensive set of licensing features, including license key generation, validation, and activation. It provides a RESTful API for integrating license management into your applications.

FastSpring: FastSpring is an e-commerce platform that offers various services, including license key generation and validation. It provides a user-friendly interface for managing licenses and supports integration with different payment gateways.

Cryptlex: Cryptlex is a cloud-based licensing solution that allows you to generate, validate, and manage license keys for your software applications. It offers a RESTful API and a range of licensing models to suit different software distribution needs.

KeyGenius: KeyGenius is a license key management platform that provides features like license key generation, validation, and activation. It also offers additional functionality such as customer management and analytics.

When choosing a web service for license key validation and generation, consider factors like pricing, ease of integration, security features, and the specific requirements of your application. It's recommended to review the documentation and features of each service to determine which one aligns best with your needs.

 

[medihub_guy]

How, exactly, do you identify the site, the location, and the workstation?

The workstation is easy enough. You can use the hard drive ID but what are you using for the other two?

And again, I remind you that I do not like this method even a little bit. I strongly suggest that you either develop your own web app to confirm the licenses or use one of the services that do this.

One of our members - @UncleGizmo is practicing using chatGP and asked this question a couple of months ago and got an answer. Try one of these to see if the tool suits you. If your product takes off, you realllllllllly do not want to be providing customized FE's for each workstation.

I use the autonumber for the site and location table. Then I use incremental numbers for the work stations based on the # of licenses at a given location.
Super simple. Haven't had any issues yet.
Nonetheless, I can be dead wrong here.

 

[medihub_guy]

Those 3 numbers create a sequence that will never be duplicated. There will only be one front end with Site # 1 Location # 2 and SiteWorkStation # 3.
If it's sound and logical I don't see the need to overcomplicate things.
Let me put things into perspective. I have a small market in the Bahamas. I do plan to take my application and make.it a web application using Java or .net once I have 20 customers.
Access is easy enough to get a prototype out on the market to make the operational use of.the application as robust as possible.

 

[Pat Hartman]

Do you control updating the site and location tables? If you don't, how can you control the values if they are in a table in the BE? How can you stop the client from changing the values if he is so inclined?

Let's put it this way and I'm going to pull rank. You are a pharmacist. You are an expert in your field. I have been designing and developing applications for 50 years. I am an expert in my field. Your method may in fact work for now even if I consider it to be clunky. But, it is not scalable and therefore will become an obstacle sooner or later. Sooner, you hope because you want to sell more copies of the FE Plus, you don't actually know that it works.

What's going to happen when you have a hundred copies of the FE out in the wild? Then you have to issue an update. What happens? Will you be sending the updated FE's to the client and leaving it to them to distribute? How will you know that they have replaced ALL the old FE's

Have you thought about how you will update the BE if necessary?

Another thing to consider. I don't know about the corporate ethics and IP (Intellectual Property) protections in the Bahamas. All I know is that you have great beaches and heart stoppingly beautiful turquoise blue water. In the US, the larger the corporation, the less likely they are to cheat on licenses (at least deliberately). They don't want to get involved in a legal battle they will lose. So, as long as the cost of your software is reasonable in their opinion, they will comply with your licensing agreement. If they don't consider the price reasonable, they will look at competitive offers or simply copy your design. They have a database and form designs. That cuts off a huge chunk of the development cycle. You might want to look into copywrite and patent law to see what you need to do. Software usually is protected by copywrite but there may be some parts that you can patent which is actually stronger protection against reproduction.

 

[Pat Hartman]

There isn't any reason to switch to a web app if Access provides the functionality you need. Using a website to validate a license is quite different from running the whole app in the Cloud.

If you go to a cloud solution, you have other issues. Are you planning on hosting it? You will need a HUGE insurance policy because if you lose the customer's data due to sloppiness or being hacked, you are dead meat so to speak.

You can create a web app that the client runs on his interweb which isolates you from certain types of data issues.

 

[medihub_guy]

Do you control updating the site and location tables? If you don't, how can you control the values if they are in a table in the BE? How can you stop the client from changing the values if he is so inclined?

Let's put it this way and I'm going to pull rank. You are a pharmacist. You are an expert in your field. I have been designing and developing applications for 50 years. I am an expert in my field. Your method may in fact work for now even if I consider it to be clunky. But, it is not scalable and therefore will become an obstacle sooner or later. Sooner, you hope because you want to sell more copies of the FE Plus, you don't actually know that it works.

What's going to happen when you have a hundred copies of the FE out in the wild? Then you have to issue an update. What happens? Will you be sending the updated FE's to the client and leaving it to them to distribute? How will you know that they have replaced ALL the old FE's

Have you thought about how you will update the BE if necessary?

Another thing to consider. I don't know about the corporate ethics and IP (Intellectual Property) protections in the Bahamas. All I know is that you have great beaches and heart stoppingly beautiful turquoise blue water. In the US, the larger the corporation, the less likely they are to cheat on licenses (at least deliberately). They don't want to get involved in a legal battle they will lose. So, as long as the cost of your software is reasonable in their opinion, they will comply with your licensing agreement. If they don't consider the price reasonable, they will look at competitive offers or simply copy your design. They have a database and form designs. That cuts off a huge chunk of the development cycle. You might want to look into copywrite and patent law to see what you need to do. Software usually is protected by copywrite but there may be some parts that you can patent which is actually stronger protection against reproduction.

Again, the end users do not have access tothe tables. It is an accde file. There are no forms available for them to change those fields.
As far as updating the software, you are involved in my other post with sharing the FE across a synced sharepoint folder. I got some good advice from other experts there of which I'm now reconsidering my model. I love that about this place. We can continue the topic of updating the FEs there.
As for wanting to change platforms, whilst access is my first love, it has its limitations and drawbacks. We all can agree to that. When I do get "big", it will be more difficult finding someone proficient in vba rather than coders who know Java for example. Security is another big topic with access as I'm sure you're aware. I've done extensive research on whether or not I can make camp at ms access and to be frank, you're one of few that thinks this is a good idea. I really wish I could but most software developers would encourage learning another language.

 

[Pat Hartman]

Again, the end users do not have access tothe tables. It is an accde file

But you said that all users at the same site share the same BE. I guess these tables are in the FE. Again, this method will work but only while you have a very small user base. You need to think "bigger". Don't create a method that will not be scalable.

it has its limitations and drawbacks

Not as much as you think. The limits and drawbacks attributed to "Access" are primarily the cause of Jet and ACE which are the desktop database engines Access, the RAD tool, is closely associated with. Once you free your data from Jet/ACE, most of those drawbacks disappear. Your max users, for example, now goes from 255 to however many seat licenses the client owns for the RDBMS you are using. The 2G data limit disappears. Most of the security issues disappear.

What we are left with is the "run on the web" issue. That is easily solved by using Citrix or Remote Desktop. I have one app that has users from San Francisco to Paris and some of the data is hosted in Farmington, CT and the rest is hosted in London. The app has local users in Farmington but all other users connect via Citrix and when the Farmington users had to work from home during COVID, the company bought a few more licenses and they just used Citrix. What Access cannot do is run in a browser so it will never be useful for sites like this one where you need to support anonymous users. I don't think your app ever needs to support anonymous users.

 

[medihub_guy]

The BE is SQL server

 

[Pat Hartman]

By using SQL Server, you've gone a long way toward eliminating the "bad" things that Access always gets blamed for.

What do you expect to gain by creating a web version? I'm not trying to talk you out of it. Your clients might prefer it because they don't understand Access either and they also might not already be running a Citrix server or Remote Desktop, although I think COVID sort of made every company jump on that bandwagon. Are you able to build the web app yourself? It is far harder than building an Access app. Integration with Office is much more difficult. I would estimate the cost of building a web app vs an Access app to be at least 8 - 1. That makes them very expensive and time consuming. And, you still probably haven't decided whether you will be licensing the app for internal use on the client's LAN or hosting it yourself on the internet with all the extra problems that will cause.

 

[medihub_guy]

But you said that all users at the same site share the same BE. I guess these tables are in the FE. Again, this method will work but only while you have a very small user base. You need to think "bigger". Don't create a method that will not be scalable.

Not as much as you think. The limits and drawbacks attributed to "Access" are primarily the cause of Jet and ACE which are the desktop database engines Access, the RAD tool, is closely associated with. Once you free your data from Jet/ACE, most of those drawbacks disappear. Your max users, for example, now goes from 255 to however many seat licenses the client owns for the RDBMS you are using. The 2G data limit disappears. Most of the security issues disappear.

What we are left with is the "run on the web" issue. That is easily solved by using Citrix or Remote Desktop. I have one app that has users from San Francisco to Paris and some of the data is hosted in Farmington, CT and the rest is hosted in London. The app has local users in Farmington but all other users connect via Citrix and when the Farmington users had to work from home during COVID, the company bought a few more licenses and they just used Citrix. What Access cannot do is run in a browser so it will never be useful for sites like this one where you need to support anonymous users. I don't think your app ever needs to support anonymous users.

I am very weak on Rest API and using it through access. Any good training on this anywhere?

By using SQL Server, you've gone a long way toward eliminating the "bad" things that Access always gets blamed for.

What do you expect to gain by creating a web version? I'm not trying to talk you out of it. Your clients might prefer it because they don't understand Access either and they also might not already be running a Citrix server or Remote Desktop, although I think COVID sort of made every company jump on that bandwagon. Are you able to build the web app yourself? It is far harder than building an Access app. Integration with Office is much more difficult. I would estimate the cost of building a web app vs an Access app to be at least 8 - 1. That makes them very expensive and time consuming. And, you still probably haven't decided whether you will be licensing the app for internal use on the client's LAN or hosting it yourself on the internet with all the extra problems that will cause.

I really am glad someone is talking me out of it. I just couldn't find sources that did. If you'd like, I'd love to briefly show you what I have created though a video chat. I am sponge!

 

[Edgar_]

There's also "Desktop As A Service" services where you pay a company for desktop seats on powerful machines. You can ask for seats in the same network so that everyone gets to access your SQL backend. They might even have something for you to protect certain aspects of the app. I'd do the web thing, after all, it's probably where everything is headed nowadays and you will probably have to do that at some point.

REST API is not hard to do, so you can still do it that way. Having a web server will cost you the VPS, the other day I bought one for 100 USD a year, and it had enough power for the apps that I hosted there. That's all you'll need to buy if you create the web server yourself.

 

[Pat Hartman]

The key to REST is finding the VB sample code.

If you'd like, I'd love to briefly show you what I have created though a video chat. I am sponge!

I'm always happy to see demos of application. If the invitation is open to all, I can host a meeting. I've recently started using Zoho instead of GoToMeeting so I need practice. I can handle as many as 25 people at a meeting.

 

[medihub_guy]

The key to REST is finding the VB sample code.

I'm always happy to see demos of application. If the invitation is open to all, I can host a meeting. I've recently started using Zoho instead of GoToMeeting so I need practice. I can handle as many as 25 people at a meeting.

you just let me know when and I'm there. Ill be happy to share what I've done.

 

[Edgar_]

Maybe I can help by posting how to tackle the usage of some REST API over the webs, there are millions, we just have to choose. Maybe you'll need to use oAuth or even google's.

 

[medihub_guy]

Maybe I can help by posting how to tackle the usage of some REST API over the webs, there are millions, we just have to choose. Maybe you'll need to use oAuth or even google's.

I would greatly appreciate that! I need it to communicate with databases like drugbank and the fda to get information in drug interactions and allergies based on the drugs ndc number.