Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / FileMaker Topics / January 2004

Tip: Looking for answers? Try searching our database.

allow user abort (off)

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
DOUGLAS HEESTAND - 23 Jan 2004 00:37 GMT
I am designing my own password/authentication scheme for a multi-file
run-time solution (because I can't figure a way to allow users to
"change password" using the built-in FM password for ALL files at
once--they would have to "change password" for EACH file!).   The
primary database file (the one they usually open first) has a short
script that prompts them for a password (if authentication is enabled)
and kicks them out after 3 failed attempts. I also have an "open"
script in each of my non-primary database files that goes something
like this:

Allow User Abort [Off]
If (Primary File::Password Enabled = "Yes" and Primary
File::Authenticated <> "Yes")
 Show Message "This Program is password protected.  Please open from
the primary file"
 Exit Application
End if

This is supposed to prevent users from opening non-primary files
directly, thereby bypassing the password authentication script.  THE
PROBLEM: if they rename or move the primary file, the If statement
produces a "Primary File could not be found..." error which the user
can just cancel!  It doesn't execute the rest of the script so I can't
trap the error and kick them out!

One solution is to just store the password locally in each database
but this seems ridiculous.  Anyone have any ideas how I can just store
the password in the primary file yet prevent users from opening
non-primary files without first entering the password?

Thanks!
comfortably numb - 23 Jan 2004 11:03 GMT
I'm no filemaker expert, but you can autoenter the inbuilt filemaker pro
password from the main file which then autoenters the passwords into the
other files when they are opened.

Then, set the other files to autoenter a dud password when opened
independently (via the document preferences) which does not allow them to
view or interact with them (no priviledges).

If the files are opened independantly of the main file they will be useless
and there will be no need for a authentication script as they will not be
able to access the file.

If the main file is opened first it will automatically enter the legit
password which will make the file accessible - this is when you run your
password authentication.

The authenticator doesn¹t need to run on any of the others as they will be
blank screened and useless - if you see what I mean!

Is this right or have I got it muxed ip?

CN


On 23/1/04 12:37 am, in article
8e66a971.0401221637.21214762@posting.google.com, "DOUGLAS HEESTAND"
<heestand@alumni.duke.edu> wrote:

> I am designing my own password/authentication scheme for a multi-file
> run-time solution (because I can't figure a way to allow users to
[quoted text clipped - 27 lines]
>
> Thanks!
DOUGLAS HEESTAND - 25 Jan 2004 07:15 GMT
Thanks for your message.  The problem with using the FM built-in
password mechanism in a multi-file solution is I can not provide an
easy way for the user the change the password.  It seems to me they
would have to change auto-entered password in each of the databases
(14 in my solution!).

Am I wrong?

Thanks!
Glenn Schwandt - 26 Jan 2004 15:23 GMT
> Thanks for your message.  The problem with using the FM built-in
> password mechanism in a multi-file solution is I can not provide an
[quoted text clipped - 5 lines]
>
> Thanks!

No, but your idea is slightly flawed.  Databases can easily be opened
without the opening script being invoked, completely bypassing your security
feature.  You need a combination of what you are doing with along with
built-in FileMaker passwords.

You set up each database in your solution with a series of identical
password and group combinations.  One password per group.  The group names
should be descriptive of what type of access the password allows.  The
passwords should be garbage that no one could ever guess.  Be sure to write
them down and put them somewhere safe, because you probably won't be able to
remember them.  There should be one password/group combination for each
level of access required in your system, from "none" to "system
administrator".

Set the "none" password as the default upon opening.  This will insure that
anyone opening your database outside of your control will not be able to do
anything.  Uncheck every option except "Browse Records" and set Available
Commands to "None".  Use the "Access Privileges Overview" to remove access
to fields and layouts.

Now, create an opener database for each of your password/group combinations.
It's only job should be to open with the appropriate "garbage" password as
default (to match it's access level defined above) and have a script that
you will call externally which should then open your main database,
effectively passing the appropriate "garbage" password and allowing the
level of access desired.  The final step of this script should close the
opener database.  The default "garbage" password should allow "none" access
in the opener database, regardless of the access it grants in the main
database.  Remember to add a password with complete access for when changes
are necessary.  Also, include a default opening script which does nothing
but close the opener database, meaning it won't function if you open it
directly.

On top of this, you put your custom password/group setup.  When an
appropriate user name and password are entered, the script is called in the
opener database that matches the access level for that user.  The FileMaker
passwords never get changed.  Do whatever you want with the ones in your
custom setup.

I can send you a set of example databases I created a while ago, if you
think that would be helpful.  Email me at schwandtg at aol dot com and I
will see if I can find them.  If not, I'll recreate them, but it may take a
little longer.
DOUGLAS HEESTAND - 31 Jan 2004 05:38 GMT
That fixed the problem.  Thank you so much your advice.  I couldn't
have done it without you.  Our solution is MUCH more secure now.
Thanks!!

-Doug
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.