Crude Login/FM Security

[ddreese]

Right now I'm just playing around with the idea of a login for my database. So far, I've started:

1. Startup file sitting on the desktop. This file opens the 'login' file on my FM server.

2. Field for username, field for password on the login layout.

3. Once the user fills out their login information, a very crude script runs:

- goto related record (based on a relationship to the user_db file, using 'username' in both files)

- if password = relationship::password

- ................

And so on and soforth. It works, which is cool because I don't know much about FM, but still got something to work. My ultimate goal is to have permissions fields in the "user_db" that will dictate what they get to change, etc. I know that you can do that with the groups/passwords thing, but I don't like many people having the same password to access the file, it would be better for me if each use had their own username/password.

What I don't understand is if I'll be able to somehow link a field in the database to a group with permissions set there. I downloaded that "gateway" template, but I couldn't really see how it worked because I couldn't even get into layout mode. So I couldn't get any ideas from there either. Whats my best mode of attack to have a login system with individual users?

[Anatoli]

We did this quite simply.

We start the same way as you described.

There are another fields, which are filled with FM password and FM group.

Then Dialog Magic plugin is login user with proper FM password/group into next file Menu. Also proper UserName is set in FM preferences.

Multiple users can be with the same group/password without knowing them or without knowing about their existence.

Users can change their passwords but FM password/group can be changed only by administrators.

HTH

[Pupiweb]

Check this tip file:

ftp://ftp.fmfiles.com/download/open/TheGateway.sit

ftp://ftp.fmfiles.com/download/open/TheGateway.zip

It's open source so you can tear it apart and/or include it in your solutions

[ddreese]

Thanks guys! I've been pretty busy the past few days, I haven't had a chance to sign on. I'll check out that plugin, it sounds like it's exactly what I'm looking for!

[Paolo]

I've implemented a similar security system.

I did that because I wanted to manage user privileges (across many database files) from a single database file and I don't like the filemaker embedded security system.

I did'n need to start from any template. I did it the way I wanted it to be. I didn't need any plugin too, fm have everything you need to do the job.

Here's how my scheme works:

1) Opener file on the desktop, it opens directly the database file you want to go (not the login db file)

2) LOGIN file: it holds usernames, passwords and privilege flags for each user.

3) LOGIN file: it contains a global field [theUser] that holds the name of the current user accessing the database. The default value is empty. If it is empty it means that the user have not authenticated yet.

4) EVERY FILE: at startup it checks if LOGIN::[theUser] is empty. If so it activates the login procedure trought a script in the LOGIN file. If the login fails Filemaker quits.

If the login succeed then the user name is stored in [theUser] and control is given back to the original file.

5) LOGIN is always opne hidden. If the user manually closes the LOGIN file filemaker must quit (because [theUser] would be restored to the befault -empty- value).

6) EVERY FILE is protected with the fm security sistem, with an administration password that gives access to the whole file.

No password (defualt) give access to the file but not to the file structure (layouts, scripts...) and not to certain menus (delete record, new record, etc...).

---

It works great for me, hope this helps...

Paolo

[ddreese]

How does the privelage flags in your login file correlate to the privelages in the built-in filemaker security?

[Paolo]

there is no correlation and, I think, no way to have it.

If you want your custom security scheme you can't rely upon the fm embedded system, you have to do all the work by yourself.

The fm security system is used only to create a single password that gives full access to the file for development/administration purposes.

Normal users enter the system (by default) with no password (no filemaker security password). They enter they username and password into the custom login filemaker database.

With <<no password>> users are not allowed to design layouts, access "Record" menu, edit scripts.

A startup script hides and locks the status bar so users can't navigate layouts.

Then you have many ways to restrict access to information upon privilege flags.

The basic, easier way to do that is trought layout design.

Suppose you have a login::LookPeopleInfo flag that gives access to personal info in a people database.

You create 2 layouts: the first contain the personal info fields, the other one don't.

Access to the layouts is provided trought a script activated by a button.

The script checks the LookPeopleInfo flag and upon its value send the user to the first layout or the second one.

There are more sophisticated techniques to restrict access (no access, read only, read/write) upon a field or record basis.

However, the most of the times, you'll have to provide a button and a script for every user action.

Users access the system in a sort of kiosk mode, with most menus disabled.

Since this is the way I make my solutions using a custom security scheme doesn't involve more work. But if actually your users can freely navigate layouts, create, delete records, the amount of design work for you will grow considerably.

Hope this helps...

[ddreese]

Thank you very much Paolo, that is an excellent explanation. I had a few other questions for you, but I think you answered them for me.

So each user has their own username, but shares either a <<no password>> or <<admin password>>, correct? I think that would be good for me on some counts, but not all. I will have to put more thought into it I suppose. Thanks again for your explanation!

[Paolo]

So each user has their own username, but shares either a <<no password>> or <<admin password>>, correct?

Yes: normal users enter the system bypassing the filemaker built-it password dialog window with default <<no password>>. Then the custom login layout shows up and they enter their name and pass.

The developer enters the system pressing option key (on macs). The filemaker built-it password dialog window shows up and he types the super-user password. Then the custom login layout shows up and he enter his name and pass; but he have access to layouts, scripts, fields, and so on...

---

If you have any other question, feel free to ask.

PS. if you are interested I can send (as attachment) my login fm file. It is very simple, and a good example explains better than 100 words.

[Vaughan]

Just to be accurate...

"Normal users enter the system (by default) with no password (no filemaker security password)."

Technically this *is* using FMP Passwords: the <no password> password is "" (null, no text). Users are not bypassing it.

[Paolo]

Yes, this is what I meant.

Every file have two fmp passwords set in the Access Privileges->Passwords:

xxxyyy ---> admin/developer password

(no password) ---> normal user password

and in the document preferences is set:

Try default password = ""

[cjaeger]

there is no correlation and, I think, no way to have it.

yes, there is. but only in AppleScript

instead of FileMaker ScriptStep "Open database" use Applescript

set mypass to cell "g_password" of current record

open "database.fp5" with password mypass

[Paolo]

This is very interesting, it let you substitute the fm password dialog with your custom fm login database.

But I think that ddreese was asking if there is a way to correlate the access privileges (normal set trought the Access privileges...->Passwods menu) with the content of a record in the same file (or a related one). And I think this is not possible.

[ddreese]

"This is very interesting, it let you substitute the fm password dialog with your custom fm login database.

But I think that ddreese was asking if there is a way to correlate the access privileges (normal set trought the Access privileges...->Passwods menu) with the content of a record in the same file (or a related one). And I think this is not possible."

Yes, that is what I was indeed asking : ) Boy, I had no idea this thread was this active. Good stuff!

[ddreese]

Paolo - I was thinking of your security setup, and it seems really intuitive. I was trying to think of a new way to do it, and I came across many of the same thoughts as you have implimented.

My next question is, does the user have to click OK every time it asks for a password for a file? What I mean is, every time the file opens, do they have to 'enter' their blank password? My database is many files, and it's only going to get larger, and I'd go nuts if I had to press 'OK' seven times just to start using the database. Can I automate that, and then how will I, the administrator log on?

This is what I'm invisioning...

The opener file opens the 'login' file. You put in your username and password, and it checks it against the 'user' file. If a field in the user file is flagged as, say, "caseworker", then it proceeds to open the appropriate files with the default password, leaving out delete, layout mode, etc.....

But if the field is flagged as 'administrator', then it would open the files using a different password, therefore giving me full access.

I haven't been able to find that Dialog Magic plugin to download, is can someone send me a link to the trial or whatever it is?: Thanks!

[Paolo]

"does the user have to click OK every time it asks for a password for a file?"

no, if you set "Try default password" as blank in the document prefs of every file.

"The opener file opens the 'login' file....."

my custom security system is different. But there are a lot of ways to do things and you have to find the best way for you.

When I want to open the file as admin I operate manually pressing option key at file opening and inserting the super-user password

[ddreese]

Thanks for all your help, Paolo. I think that's probably my best bet for a simple login system. I'll let you know how it works out for me : )