Preventing end users from using copies of your front end - the solution

[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.

 

[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?

 

[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.

 

[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.

 

[medihub_guy]

The BE is SQL server

 

[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.

 

[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.

 

[Edgar_]

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.

Whoa! very interesting, checked some meds using their search and now I'm worried!

Do you have an API key? I just checked and I couldn't find a way to get one without going through their sales department, I hope they contact me though. Anyways, by their docs, it looks just like other services out there (trivial, and Access can use it).

 

[TheSearcher]

Place a configuration file somewhere on the C drive (It doesn't need to have any contents) of all paying customers during installation. Then check to see if it exists. If not then Quit the app.

Dim IsItThere As Boolean

'*** Security Check in Login Form.
IsItThere = DoesFileExist("c:\zxmod\zxmod.cfg")
    If IsItThere = False Then
    MsgBox "Configuration file is Missing.", vbCritical, "ClientTrack"
    DoCmd.Quit
End If

'*** Function to see if file exists

Public Function DoesFileExist(ByVal strFile As String)

    Dim lngAttributes As Long

    lngAttributes = (vbReadOnly Or vbHidden Or vbSystem)

    Do While Right$(strFile, 1) = "\"
        strFile = Left$(strFile, Len(strFile) - 1)
    Loop

    'If Dir() returns something, the file exists.
    On Error Resume Next
    DoesFileExist = (Len(Dir(strFile, lngAttributes)) > 0)
    
End Function

 

[Luis Fernandez]

My solution, I have a text in the Windows registry that I check to see if I am authorized.
I do this authorization through a key that shows the application and that contains some bios checksums and other parameters of the equipment, the system and the allowed dates of use, to which I send another key that complements it and authorizes what I want.
This key will not work on another computer.
The Windows registry can be easily manipulated with GetSetting and SetSetting
The system can also access an authorization website to see if it is active and if not, close it.
It will only allow it to function for some time without line
This way you can remotely close the application you want, by its ID or something similar

 

[Edgar_]

What causes the initial registry entry to be written?

An installation?

 

[Edgar_]

I guess I wasn't clear. Where does the value for the setting come from and when does it get applied? Since it seems to be based on some local value, it would seem like the "installation" would somehow need to be customized ahead of time for each computer if this is the case.

Maybe

The system can also access an authorization website to see if it is active and if not, close it.

But yeah, maybe Luis will clarify that. Still vulnerable though. One could edit the registry entries or remove the authentication part from the code.

 

[Luis Fernandez]

Maybe

But yeah, maybe Luis will clarify that. Still vulnerable though. One could edit the registry entries or remove the authentication part from the code.

Of course you can try to search for the registry modification by comparing it with a previous version but
1.- You do not know what the entry is called, if your system is called "My system" the entry may be jhfjkdfsjkfggfyg
2.- Deleting it only blocks the system
3.- the correct password only works for one device, App and dates

 

[Luis Fernandez]

What causes the initial registry entry to be written?

When opening, the system looks for your password in the registry; if it does not exist, it creates it as unauthorized.
Before or after with the authorizing program, I authorize live or remotely, also by email key, the real key with the real options that the client purchased.
The program installed on the client initially gives me the computer data through a key like Windows, then I send the authorization key

The key of the equipment installed on the client tells me which equipment it is (unique) for that I base it on whatever I want, bios configuration, descriptions of the motherboard (texts that Windows Info offers) installed cards, installed disks.
Any modification to the computer, and of course cloning the hard drive and using it on another computer will make it stop working.

In the past I had it very restricted and changing a mouse from PS2 to USB deactivated the system and we had to see if it was that case or a clone, if the client wants to change equipment, first uninstall and with that I know that I only have to install once.
It only fails if the team dies, I decide if I give away a key or not

 

[Edgar_]

With Access, keeping things secure is a gamble. You can add some locks, but it's quite simple for someone to break into an Access app. Sharing ways to break in or share unlocked apps depends on the person doing it. So, I suggest not relying on Access for security and using a different platform instead. Often, when you make a niche app that people want, you can sell it to that niche group. But sometimes, there's someone who doesn't want to pay and tries to use it for free. They might hire someone to hack it or try to do it themselves and either give it away for free or at a reduced cost.

Anyway, good luck. Hope that never happens.

 

[Luis Fernandez]

I have not been cracked since '87, of course I have only had about 300 clients, it is not industrial or massive, I did not have the necessary capital to do it well, and sell it as a standard package, dealing with clients and their adaptations was very personal, but After several sales, the adaptations worked for everyone and I had a fairly commercial product.