UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V  1 2 >  (Go to first unread post)
   Reply to this topicStart new topic
> Changing Windows Date Coaxed My Access Pawn App, Any Version    
 
   
FrankRuperto
post Jun 3 2020, 09:57 AM
Post#1



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


My pawn app relies on current Windows Date/Time for proper calculations, record creation/edits, etc.
I disabled end-users ability to change Windows Date/Time in Local Security Policies > User Rights.
I just discovered an end-user somehow bypassed the policy restriction and changed the system date to coax my app into thinking yesterday is current day.
That change created more complications. User then open the backend and directly edited dates in several records.
Is there a way my frontend can detect and immediately exit the app if Windows Date/Time has been changed?
Is there a way I can prevent users from directly opening the accdb backend?
This post has been edited by FrankRuperto: Jun 3 2020, 10:31 AM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
theDBguy
post Jun 3 2020, 10:03 AM
Post#2


UA Moderator
Posts: 78,481
Joined: 19-June 07
From: SunnySandyEggo


Hi Frank. This may or may not help, but I use it to prevent or handle the issue when users change the system clock. Cheers!

Retrieve Greenwich Mean Time

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
GroverParkGeorge
post Jun 3 2020, 10:05 AM
Post#3


UA Admin
Posts: 37,503
Joined: 20-June 02
From: Newcastle, WA


"I disabled users ability to change Windows Date/Time in Local Security Policies > User Rights."

Are you actually doing this on computers of people who have purchased your Pawn Shop App? Or are you only restricting your own employees' computers?



--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
FrankRuperto
post Jun 3 2020, 10:16 AM
Post#4



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


Hi DBG.

That's a good technique. Unfortunately, my users work in offline mode. When my app opens, it creates a current day drawer record if one doesn't exist. Perhaps I can use the Max DrawerDate to compare against Windows Date.

What about preventing users from directly opening the accdb backend?

Thanks, Frank

---

Hi Geroge,

Disabled for all end-users running my app. Is that dangerous?
This post has been edited by FrankRuperto: Jun 3 2020, 10:29 AM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
GroverParkGeorge
post Jun 3 2020, 10:35 AM
Post#5


UA Admin
Posts: 37,503
Joined: 20-June 02
From: Newcastle, WA


So to be clear. You sell your app to a pawn shop. As part of your app, you change how their Operating System functions? Dangerous, maybe. Ethical, maybe. What does your legal advisor have to say about this? Do you hve an agreement with your users to take control over their OS?
This post has been edited by GroverParkGeorge: Jun 3 2020, 10:40 AM

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
FrankRuperto
post Jun 3 2020, 10:56 AM
Post#6



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


Yes it's legally on our agreement. We're essentially their IT that manages all their hardware and software. If they make any changes without first contacting us and getting our approval, we cannot be held responsible and they would have to pay us to fix whatever.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
theDBguy
post Jun 3 2020, 11:01 AM
Post#7


UA Moderator
Posts: 78,481
Joined: 19-June 07
From: SunnySandyEggo


QUOTE (FrankRuperto)
What about preventing users from directly opening the accdb backend?

Hi Frank. One approach is to encrypt the BE file with a password and then use an intermediary file as a bridge between the FE and the BE. The FE connects to the middle file and the middle file will use the password to connect to the BE using code, so the password cannot be seen by the user. Or, if you don't want to use a middle file, you can remove all linked tables in the FE and simply use code to get and update the data from the BE.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
FrankRuperto
post Jun 3 2020, 11:07 AM
Post#8



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


Can both methods you suggest guarantee end-users will not be able to directly edit tables?

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
theDBguy
post Jun 3 2020, 11:24 AM
Post#9


UA Moderator
Posts: 78,481
Joined: 19-June 07
From: SunnySandyEggo


QUOTE (FrankRuperty)
Can both methods you suggest guarantee end-users will not be able to directly edit tables?

Since we're talking about an Access database, I wouldn't say 100% guarantee. However, for most users, I would say 99% guarantee.

PS. Let's put it this way, if you don't know the password to an Access file, how can you edit the data in its tables? If you know a way, and your users know it too, then there can be no guarantee they can't get to the table and modify the data. In that case, maybe it's time to use something else other than Access. I think password-protecting the BE file is the basis for a good security measure.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
FrankRuperto
post Jun 3 2020, 12:01 PM
Post#10



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


Agreed, it can't be 100% foolproof, just looking for a pretty good way for preventing my average end-users from directly editing tables. I have the accde frontend locked-down pretty good, so they cant link to the tables from there.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
theDBguy
post Jun 3 2020, 12:03 PM
Post#11


UA Moderator
Posts: 78,481
Joined: 19-June 07
From: SunnySandyEggo


So, if they can't "mess" with the FE, then adding a password to the BE and not telling them what it is, should keep them away from the BE too. Right?

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
cheekybuddha
post Jun 3 2020, 12:08 PM
Post#12


UtterAccess Moderator
Posts: 13,042
Joined: 6-December 03
From: Telegraph Hill


I thought you were using Postgres as your BE, Frank?

--------------------


Regards,

David Marten
Go to the top of the page
 
FrankRuperto
post Jun 3 2020, 12:15 PM
Post#13



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


Not for the pawn app. PostgreSQL BE is for other non-pawn users we have running desktop/web hybrid apps. The BE's live on Linux servers and are shared with Access and php frontends. However, we're in the process of rewriting the pawn app to use php browser-based FE's with PostgreSQL on a localhosted intranet. However, reality is not all users will want to migrate from Access, so we will have to continue supporting both versions.

At least the Access users will have a migration option should the wheels fall off Access and/or Windows.
This post has been edited by FrankRuperto: Jun 3 2020, 12:49 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
FrankRuperto
post Jun 3 2020, 12:39 PM
Post#14



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


QUOTE (DBG)
So, if they can't "mess" with the FE, then adding a password to the BE and not telling them what it is, should keep them away from the BE too. Right?

Agreed. Thanks for your suggested methods, I will consult with my developers and decide which of the 2 ways you suggested we should implement.

QUOTE
... remove all linked tables in the FE and simply use code to get and update the data from the BE.

Preliminarily, I'm leaning towards doing it this way. Would we have to supply the BE password in the vba to link to the tables via code?
This post has been edited by FrankRuperto: Jun 3 2020, 12:40 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
theDBguy
post Jun 3 2020, 01:12 PM
Post#15


UA Moderator
Posts: 78,481
Joined: 19-June 07
From: SunnySandyEggo


QUOTE (FrankRuperto)
Preliminarily, I'm leaning towards doing it this way. Would we have to supply the BE password in the vba to link to the tables via code?

Yes, but you can encrypt it also, so it can't be viewed with a hex editor.

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Access Website | Access Blog | Email
Go to the top of the page
 
AlbertKallal
post Jun 3 2020, 01:45 PM
Post#16


UtterAccess VIP
Posts: 3,102
Joined: 12-April 07
From: Edmonton, Alberta Canada


Preveting of opening back end?

Here is what I done in the past:

disable the shift key by-pass (and few users know about this, but its a good idea). I have a utility here that sets or un-sets the shift by-pass key for any database (you just browse to the database).

The next thing I do is setup a autoexec macro - it can call a VBA routine or you can even write the macro code in place of VBA.

I simply pop up this message box:



When it hit ok, then I do a application quit.

the auto exec macro looks like this:




So, users click on the back end - it opens and gives that scary message. It then shuts down when they hit ok. Now this is not super secure or anything, but I have found that 9 out 10 times - the user gives up on trying to mess with the back end. It is for this kind of stuff we really kind of miss the ULS security that Access once had (it again was not bulletproof, but it really did help keep people out).

Now, the above will not stop a user from launching access and THEN opening the back end - but again in most cases they don't know about shift key by-pass, and they again get that official looking message box, hit ok and the application shuts down.

You add in shift-key by-pass (disable) and the above simple message? You would be AMAZED how well this works for 99 out of 100 users!


So, the above idea is what I do, and it goes a really long way towards keeping most casual users - even those with some access experience out of the back end. Even if they launch full access and open that back end, the autoexec macro STILL runs unless they know about the shift key. But then again, we turned off the shift key - right???

And for date changes? Well for both SQL applications, and even split FE/BE applications? On startup I pull the date from the server where the BE is (there is a simple API call to do this - I'll try and dig it up). So, on application startup if the workstation data is less then the computer's date were the BE is, I give a message and exit. You can also execute a set time from Access on startup without telling them, and that can also work, but exiting the application is best. Note that a smart user could launch the application and THEN change the workstation data. But I had a few places (such as when I return to the main menu/form that gets/grabs the server date/time, and compares it to the local date/time. So even a user tampering with workstation dates would still see/get a warning - even if they changed the date AFTER launching the program. This again thwarted most users.

Some smart user would not figure out if they actually launched the one form, and THEN changed workstation date, and THEN entering some data they might get around date restrictions. But as noted, they tend to change the date, and then launch the application - so with this simple pull the date/time from the server where the accDB back end is, it thus prevented this problem in most cases. And as noted the main menu form did the BE date/time pull, so even if they changed date after launching, they tend to see that message about their workstation date being wrong.


R
Albert
Go to the top of the page
 
FrankRuperto
post Jun 3 2020, 07:35 PM
Post#17



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


Also good Albert, but what if users start searching the web for ways to crack Access?... Just as we did with the frontend, disabling shift-bypass and a combo of other things to make it harder to crack, I suppose we can apply multiple techniques, including your suggestions and DBG's, to protect the backend.

Utter-Access related-posts are some of the top search results when searching about this topic.
This post has been edited by FrankRuperto: Jun 3 2020, 07:40 PM

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
AlbertKallal
post Jun 4 2020, 02:32 AM
Post#18


UtterAccess VIP
Posts: 3,102
Joined: 12-April 07
From: Edmonton, Alberta Canada


True, but even then, users have to "know" that you disabled the shift key by-pass.

Uses often don't think of that.

As I stated, it not bullet proof, but it does help. I mean those users that you note that did open the back end, and mess around?
A good chance they would not have got in - can't be sure, but it does help.

I mean, the only other alternative is to use SQL server or some server based back end - and use the linked table trick without uid/password as part of the table links.

That way, users will never know the password to the database.

So, this trick of shift key by-pass and a simple message as per above is certainly better then nothing - you really don't have any great options here, and thus this 5 minutes of time will at least give you better protection then nothing at all.

R
Albert
Go to the top of the page
 
FrankRuperto
post Jun 5 2020, 08:46 AM
Post#19



Posts: 1,102
Joined: 21-September 14
From: Tampa, Florida USA


I also agree with that Albert. Has anyone encountered situations where users intentionally changed Windows Date/Time to backdate or postdate records? I have also seen users accidentally setting a Windows PM time instead of AM, and vice versa, causing problems which sometimes goes undetected for days. Most desktop and web applications depend on obtaining the correct date/time.

--------------------
Currently supporting pawnbrokers that use my store management system developed with Access 2010 on Windows7. Experienced with Informix, Oracle & PostgreSQL db's.
Go to the top of the page
 
cheekybuddha
post Jun 5 2020, 08:57 AM
Post#20


UtterAccess Moderator
Posts: 13,042
Joined: 6-December 03
From: Telegraph Hill


>> Most desktop and web applications depend on obtaining the correct date/time. <<

Most easily done by connecting to the internet! Sending you round in circles!

Does your app connect to a server? You could perhaps try and check the time on that, or another networked computer.

--------------------


Regards,

David Marten
Go to the top of the page
 
2 Pages V  1 2 >


Custom Search


RSSSearch   Top   Lo-Fi    11th July 2020 - 05:41 AM