By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,155 Members | 2,563 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,155 IT Pros & Developers. It's quick & easy.

Start secure file without logging in a second time

P: n/a
A2k2 with user-level security and all preventive measures, vis a vis,
Security FAQ enabled or enacted.

I've got three DBs, which due to size constraints can't, or rather,
probably shouldn't be combined. All have front-end on C: drive,
back-end in same folder on network share. All are secured with the same
..mdw.

I'd like to make a master file that gives the user one single jumping
off point to link to the other apps. I can accomplish what I want using
a Shell function, but I just wind up having to log in again, as each of
the other apps is started. I'd prefer not to hard-code passwords, etc.
into the code.

I haven't found a way to successfully open a new database in a single
instance of Access, which is what I'm aiming for to avoid
authenticating in the .mdw, again. Anyone have any experience with this
kind of functionality or know a way to get the desired results?

Thanks in advance...

Nov 21 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
What you do is of course for all secured mdb databases, you use a shortcut
to the mdw file...right?

This means that for all normal databases (those un-secured), users will NOT
be nagged to death with a logon.

So, then all you do is make you "launch" pad system - leave it un-secured,
but then build your own custom logon form. Since the launch pad does
nothing, then that code is absolute minimal (a prompt form with name +
password).

Then, to launch any, and all other databases, you simply shell out, and add
the user + password as the command line switches....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
Nov 22 '06 #2

P: n/a
Yah, I looked at that sort of thing, but couldn't get it to integrate
with the .mdw. I'd like not to store login ids or pwds any place except
the .mdw, but haven't been able to replace the login prompt with my
own. I suppose I could access the security structure in the .mdw via
DAO or ADOX, but that may be more overhead than it's worth.

Albert D. Kallal wrote:
What you do is of course for all secured mdb databases, you use a shortcut
to the mdw file...right?

This means that for all normal databases (those un-secured), users will NOT
be nagged to death with a logon.

So, then all you do is make you "launch" pad system - leave it un-secured,
but then build your own custom logon form. Since the launch pad does
nothing, then that code is absolute minimal (a prompt form with name +
password).

Then, to launch any, and all other databases, you simply shell out, and add
the user + password as the command line switches....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
Nov 22 '06 #3

P: n/a
"Jamey Shuemaker" <ca*********@yahoo.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
Yah, I looked at that sort of thing, but couldn't get it to integrate
with the .mdw.
You don't have to. All you do is prompt the user for password, and logonID.
I'd like not to store login ids or pwds any place except
the .mdw,
Yes, that is exactly what I been suggesting.
but haven't been able to replace the login prompt with my
own.
Why will the launch pad ask for a logon if your launch pad program is not
secured? (answer: it will not, assuming you read, and followed my other
post - I suggested to NOT JOIN the secured workgroup file, and that way all
mdb's that you launch will NOT prompt for passwords or logons - I STRONGLY
suggest that you do this anyway. (why have ALL mdb files nag and prompt
users?). What happens if they place other mdb files on their machine that
are not secured??? No need to set the workgroup file. Stay attached to the
default one, and ONLY use the workgroup file via a shortcut. So, don't
join the secured workgroup file, but use a shortcut for those secured ones
(so, users don't get messed with when using toher mdb files - or, what
happens if they have antoher seucred mdb file with a differnt workgroup?
that "other" applcation will then mess up yours if they also need to be
set to a particlar workgroup. Using shorcuts ellmonates this problem.

Further, for our idea, will
simply *shell* out to that secured mdb file, and will provide the path name
to the security workgroup file AND ALSO THE COMMAND LINE switches with the
user name and password.
I suppose I could access the security structure in the .mdw via
DAO or ADOX, but that may be more overhead than it's worth.
NO not suggesting this at all...

You not storing the users logion in a table, but simply prompting the user
for their logon name, and logon password Once you done that prompting, you
have their logon name + password storing in variables in the program - Not
in a table.

You simple prompted the user for the password, and logon name. You can now
shell to any secured database, and supply the passwrod+logon that the user
just gave you.

From my last post:
<quote>
Then, to launch any, and all other databases, you simply shell out, and add
the user + password as the command line switches....
</quote>

Of course, the only *slight* problem with the above is that during the logon
process, if the user id/and or password typed in is WRONG, then they will
ONLY find this out when you actually try and shell out to those secured
databases, not during your "fake" logon process. However, once they do type
in a legitimate logon and userID, then the shelling out will work.

Further, you *could* add code to the logon process to actually open that
other secured database during the logon process, and verify if the password+
logon is legitimate (but, lets fry one fish at a time).

So, first, lets just get the shell code working (you likey have that now
anyway).

The code to do this (well, you would build a nice logon form), but the meat
is building a shortcut...:

"C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE"
"c:\program files\RidesXP\RidesXP.mdb"
/wrkgrp "c:\Program Files\RidesXP\Rides.mdw"
/User "RidesAdmin" /pwd "mypassword"

So, a shortcut that shells out to ms-access can supply that users name, and
logon. We don't nothing to actually verify that the logon and password is
legitimate.

q = chr$(34) ' a double quote (")

strLogOn = inputbox("Enter your logon")
strPassword = inputbox("Enter password")

Now, just build shell string with the above....

strCurrentDir = CurrentProject.Path & "\"

' path to msaccess is required here
strShellProg = q & SysCmd(acSysCmdAccessDir) & "msaccess.exe" & q & " "

' path to current dir...and upgrade...
strShellProg = strShellProg & q & strCurrentDir & "UpGrade.mde"

strShellProg = strShellProg & _
" /user " & q & strLogOn" & q & " /pwd " & q & strPassword & q

Shell strShellProg

The above is not 100% correct, but is quote close to teh idea here.
Above I am shelling out to mdb called upgrade, but it
could just as well been what you selected on your launch pad. You can see
that NOTHING is stopping you from prompting the user for logon+passwrod. You
then simply use that as part of the shell process. Note how the above does
not HARD code the path name to ms-access.exe, since it will OFTEN be
different on different pc's. (so, don't hard code path to the .exet).

Once you get the above working, then you can start adding code that actually
tries to *open* (not shell!!) that database on the password + logon given.
This is a *can* part, but is NOT required.

Here is another code snip that gives some ideas about opening a secured
database to actually verify what the user typed in:

to open a table in your current database, you go:

dim rstDataTable as dao.recordset
dim myDB as dao.database

set myDB = currentdb
setrstData = currentdb.OpenRecordSet("mytable")

normally, to open *another* database (not load, or run BUT SIMPLY OPEN!!!).
You take the above code, and go:

dim rstDataTable as dao.recordset
dim myDB as dao.database

set myDB = openDatabase("path name to any mdb file")
setrstData = currentdb.OpenRecordSet("mytable")

Right? You done the above two things many times (I mean, in code, how else
did you ever open other databases?????). The problem is that in our 2nd
example, we want to open a *secured* database, but how to some how supply
the user log on and password (but, low, and behold...we asked the user for
that!!!).
So, code to open a secured database is more complex, but we CAN do this...
eg:

Dim dbe As DAO.PrivDBEngine
Dim wrk As DAO.Workspace
Dim dbs As DAO.Database

Dim rstTables As DAO.Recordset

' setup new workgroup
' Return a reference to a new instance of the PrivDBEngine object.
' we have to do this to OPEN a file with a DIFFERNT workgroup

Set dbe = New PrivDBEngine
' Set the SystemDB property to specify the workgroup file.
dbe.SystemDB = "path name to workgroup file"

dbe.DefaultUser = Me.txtUser ' user logon
dbe.DefaultPassword = Me.txtPass ' user passowrd
Set wrk = dbe.Workspaces(0)
' Open the secured database.

Set dbs = wrk.OpenDatabase(Me.Text0)

' database open...now grab table list...

I don't think it needs explain that if the above code fails to open the
secured database, then obviously the user supplied password and name are
wrong!!! (so, again, do I really need to explain that if you can't open a
secured database with a username + password you prompted for, then obviously
that user name + password is wrong!!!..right?). So, simply "test" open one
of those several databases that you want to shell out to. (add this code to
your above logon procdure)

Certainly not a lot of code here, but just a question of realizing that if
we prompt the user for their name+password, we don't have to store it
anywhere, but simply use that in our code that shells out. As I said,
actually verifying if the supposed name+passowrd is actually optional,
but the above shows this is also possbile...

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

Nov 22 '06 #4

P: n/a
Albert D. Kallal wrote:
"Jamey Shuemaker" <ca*********@yahoo.comwrote in message
news:11**********************@h48g2000cwc.googlegr oups.com...
...
Sorry for the tardy reply, Thanksgiving weekend here in the US, and
all....

I've already set up a structure like the one above, with the exception
of requiring the custom logon prompt when the user first selects a
secure .mdb/.mde from the navigation tableau that provides all Shell
shortcuts, and then never again, provided the information is correct.
Under that structure the current logon prompt verifies the password
structurally, first, then verifies the actual password and username
stored in the .mdw. The syntax for password is more rigorous than the
typical 14 character password required for DAO.Workspaces including an
alphabetic character, number and a non-alphanumeric character.

The second structure under consideration is just opening the database
with the Shell command without the username and password info and
having the user authenticate each time they log into any secured
database in the tableau.

The only advantages I see to the first approach, as suggested, is
storing the username and password elements as variables in the unsecure
database to prevent the requirement for repetitive logins. The tableau
would be an .mde to prevent access to the underlying variables, but I'm
still not sure of the security implications of storing those types of
variables on the user's machine while the tableau is open and running.
Obviously, it seems that this method implies "looser" security than a
simple shortcut on the desktop to open these files. Are those concerns
unfounded, and if not, what perils do you foresee for this type of
structure?

Nov 25 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.