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

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Re-enabling A Bypassed Shift-key, Any Version    
 
   
CyberCow
post Sep 26 2006, 10:09 AM
Post#1


UdderAccess Admin + UA Ruler
Posts: 19,557
Joined: 27-April 02
From: Upper MI


This post serves to provide a method to re-instate the Shift-Key bypass feature when it is disabled with the methods shown here. All the procedures below should be placed in a module, not in the code behind any form.
There are many ways to disable the Shift-Key bypass function in Access. It may also vary by the version of Access. (As I work primarily in Access 97, the functions included in this dissertation have not been tested in other versions.)
TO DISABLE THE SHIFT-KEY:
You need a procedure that will disable the shift-key (you may want to also disable other key functions). . .
CODE
Public Function devlock()
10      ChangeProperty "AllowBreakIntoCode", dbBoolean, False  ' turn OFF the Break into code feature
20      ChangeProperty "AllowSpecialKeys", dbBoolean, False    ' turn OFF the Special Keys feature
30      ChangeProperty "AllowBypassKey", dbBoolean, False      ' turn OFF the Shift-Key Bypass feature
  
End Function

Seeing as "ChangeProperty" is not a native Access function, we will need the code for that as well . . .
CHANGE PROPERTY FUNCTION:
CODE
Function ChangeProperty(strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer
Dim dbs As Database, prp As Property
Const conPropNotFoundError = 3270
10    Set dbs = CurrentDb
20    On Error GoTo Change_Err
30    dbs.Properties(strPropName) = varPropValue
40    ChangeProperty = True
          
Change_Bye:
50    Exit Function
          
Change_Err:
60    If err = conPropNotFoundError Then  ' Property not found.
70        Set prp = dbs.CreateProperty(strPropName, varPropType, varPropValue)
80        dbs.Properties.Append prp
90        Resume Next
100     Else        ' Unknown error.
110       ChangeProperty = False
120       Resume Change_Bye
130   End If
          
End Function

So, to lock your db before distribution, simply enter "devlock" on a new line in the debug window and press enter. When next you open the db, it will be Shift-Key disabled.
However, once the Shift-Key is disabled, you won't be able to get back into design mode unless you provide an unlocking mechanism. Access can be launched from a command line prompt. The easiest way to get to a command line prompt is to click the start button in the lower-left-hand corner of the desktop, then select "Run..." There you see what is called a command prompt.
To launch your app with a command line, use something like this:
"C:\Program Files\Microsoft Office\Office\Msaccess.exe" C:\DBDirPath\NameOfDB.MDB /cmd "secretpassword"
Then, in your app, you need a procedure to check for the password. It is important that the procedure below is one of the first things executed when your app launches. I suggest calling it from an AutoExec macro or in the OnOpen procedure of the first form that loads. And it requires the "ChangeProperty" function above.
CODE
Public Function unlockdb()
  
10  If Command = "secretpassword" Then
20      ChangeProperty "AllowBreakIntoCode", dbBoolean, True  ' turn ON the Break into code feature
30      ChangeProperty "AllowSpecialKeys", dbBoolean, True    ' turn ON the Special Keys feature
40      ChangeProperty "AllowBypassKey", dbBoolean, True      ' turn ON the Shift-Key Bypass feature
50  End If
End Function

Executing a property change does not occur within the current session of the running app. The next time the app is launched, the property change will be instantiated. So you must close and re-open the app for the change to take place.
Now, what if I want to get everyone out of the pool so I can modify the back-end of any given database? For this, I use a simple file-existence method. Every front-end is set up to have the main menu up at all times. In the main menu are two situations that occur;
1) A user cannot close the main menu except by quitting the application with the command button that says "Quit"
2) The main menu has an OnTimer event that checks for the existence of file in the back-end directory every minute. It is this OnTimer event that provides the ability to put all users out of the pool.
The OnTimer event checks the server for a specific file name. (In this case "db1.loc") If that file appears on the server at the location designated in the code, the user is given a message form indicating that they have 2 minutes to save what they are doing before the application closes automatically. Also, as long as the "db1.loc" exists on the server, the app will not launch as the very first routine run by every front-end checks for the existence of that file, and if found, tells the user that db cannot be run until maintenance is complete.
Further, each front-end also checks the version of the distribution copy of the front-end, which is housed on the server. I maintain a "SysInfo" table in each db to hold version and other info. It is always a one record file. When the app launches, after the loc file check routine, the desktop version is checked against the server version and if they do not match, the app closes and another app launches to upgrade the user's version.
Finally, if I need to make a tweak at a user's station, a provision exists for that as well. The title label of the main menu is double-click-able so it will open an inputbox, asking for the Development Password. If the correct password is given, immediately, the tool/menu bars are turned back on, the db window is displayed and the debug window is opened. This does not re-enable the Shift-Key bypass, it merely turns those items on for the current session. When the tweaks are complete, the app is relaunched to re-disable the hidden features.
To add/remove line numbers in code, I use another of Leban's cool tools: Code Comment Builder Wizard (Access 97) or Line Numbers (Access 2000)
Go to the top of the page
 
TheSmileyCoder
post Oct 10 2012, 04:31 AM
Post#2


UtterAccess VIP
Posts: 1,529
Joined: 19-January 12
From: Denmark, Copenhagen


In theory your devlock looks very nice. But as far as I know you can simply re-enable the shift key from outside the datebase (I know I do - in access 2010)
On the Line where you write:
CODE
Set dbs = CurrentDb

You replace it with
with strDB being the path to your database.
So even though you have password protected the property from within the database, I can just use another office application with VBA (Or probably a VB script) to re-enable the bypass key.
In the end, your database will not be "password" secured even though you think it is. If security is your main and primary concern, then I don't think access is your correct platform.
Go to the top of the page
 
CyberCow
post Oct 10 2012, 10:35 AM
Post#3


UdderAccess Admin + UA Ruler
Posts: 19,557
Joined: 27-April 02
From: Upper MI


A little further analysis indicates that when the db you want to secure has a database password set, you MUST know the password to get past the enable/disable code - remotely or not. Period.
However, for someone who is supposed to be able to use the application, they will need to know the password to be able to use it. And, if a user with password access fiddles about with the shift-bypass or attempts to gain edit mode, they would then be in violation of company policy - if such a policy exists.
Again, it falls back to audience. If you know your user-base and have an avenue of enforcing company security policy, an Access db with a disabled shift-bypass and db level password protection should be enough to thwart any hacking attempts.
If your deployment is wider spread than can be covered by a company policy, then Access is not the proper repository tool.
HAs an example, can anyone get into this db? : (note: this attachment is an Access 2010 db)
Attached File  AudioDemoSec.zip ( 657.01K )Number of downloads: 382
Go to the top of the page
 
TheSmileyCoder
post Oct 10 2012, 01:46 PM
Post#4


UtterAccess VIP
Posts: 1,529
Joined: 19-January 12
From: Denmark, Copenhagen


I have played around with your demo a bit, without luck getting into it. I haven't tried any third party tool to open it.
I have tried:
Enabling shift key from outside (another db)
Holding down shift (durr)
Import from another db
Looking at the file in notepad
They all failed. That said, if you distribute the same password to 30 people you might as well write it as part of the filename <
Oagree completely with you, that you should secure your access database to a reasonable degree. To me this means:
Splitting frontend from backend.
Make it a MDE / ACCDE
Disable Special hotkeys
Hide navigation pane
Hide ribbon
You could go beyond this, I am sure, adding password protection could be one step.
However in the end I agree with you on your last point as well, if you want total security access is not your tool of choice. If you want rapid development and lots of lots of versatility and a reasonable degree of security access is the best on the market (in my opinion).
Go to the top of the page
 
milly62
post Mar 24 2020, 07:40 AM
Post#5



Posts: 3
Joined: 28-June 18



Hello. I followed the steps from .....https://docs.microsoft.com/en-us/office/tro...startup-options...... and I modified a database. Now, it is with ShiftKey disable. How can I re-enter to change it?

Can someone help me????
This post has been edited by milly62: Mar 24 2020, 07:42 AM
Go to the top of the page
 
isladogs
post Mar 24 2020, 12:11 PM
Post#6


UtterAccess VIP
Posts: 2,232
Joined: 4-June 18
From: Somerset, UK


Crossposted with a response at https://www.access-programmers.co.UK/forums...5/#post-1679067

--------------------
Colin (Mendip Data Systems)
Website, email
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    29th March 2020 - 03:55 AM