Solved

User access

Posted on 2003-11-09
13
318 Views
Last Modified: 2010-04-27
How do I write a script to allow each user to only view their own record. For example, i want john to view only the records with employee ID = john.
0
Comment
Question by:treynathan
  • 4
  • 3
  • 2
  • +1
13 Comments
 
LVL 3

Expert Comment

by:D0N
ID: 9715676
I would set up a relationship which displayed only the records created by Status(CurrentUserName).
0
 
LVL 3

Expert Comment

by:Mariano_Peterson
ID: 9718806
You have to be much more specific about what you are trying to accomplish.  Without more details, it is extremely difficult to guess what the appropriate solution is.

Do you mean the user will be searching and browsing records, and the results of all finds should be limited to only show records where employee ID = john?
How about after performing "go to related records"?  Should the resulting set be limited also to only show john?
How about when performing a find all?  Should the resulting set be limited also to only show john?
How about scripted reports that perform automated finds for reporting data?  Should those reports be filtered to only show john?
How do you determine the user's name?  Do you have a login system, or are you relying on the application preferences (status (currentUserName)?

The best bet (and easiest method) will probably be to set up a password that only allows the use to browse a limited set of records.  Then, in the definition for the limited set, you can configure it so the user can only view records assigned to themselves.

--
On a seperate note, key fields (such as employee ID) should never be based on significant data like the user's name.  Rather, keys should _always_ be given insignificant values such as serial numbers.  If you use the user's name as a value for a key field, you'll have to be very careful about when and how people change the user's name.  Also, significant data is frequently subject to change - which puts the referential integrity of your data at high risk.  On the other hand, insignificant data will never change, so the referential integrity of your data is much more secure.

It really sounds more and more like you are just beginning to learn about databases (which is a good thing =) ).  However, if you build a database before you have any understanding at all of database design principles, you will likely paint yourself into a corner where the database is not flexible enough to meet your business needs, and more importantly, you are likely to build a database that will loose and/or corrupt data because of design errors (like using the username as a key).

I highly recommend you read a book about database design before you proceed.  Just read the first chapter or two of any SQL book.  There are books on plain old SQL, or you can get a book on SQL Server or Oracle or other.  No matter the book, the first few chapters are almost always the same.

Good luck,
Mariano
0
 

Author Comment

by:treynathan
ID: 9719599
I want to go for the best bet. I just want John to see only the record relating to him ( i mean the record with his his ID) when he logs in using a password. Since you said using insignificant values such as serial number is better. then maybe i'll using keys like employee ID. And so now, how do we go from here?
0
 
LVL 3

Expert Comment

by:Mariano_Peterson
ID: 9719808
How are you currently identifying the current user?  Is it just by status(currentusername)?  Status( currentusername) is derived from the data in the user preferences (Edit > Preferences > Application).  The problem with that is that anybody can just change the user name to that of somebody else.  Then, they'd have access to the other person's record.  So, status(currentusername) is not secure.

What you need to securely identify the user is a secure login module.  Chris Moyer and Bob Bower's book, "Advanced FileMaker Pro 5.5 Techniques for Developers", has a chapter or two devoted to this topic, and the CD has a sample login system included.  The login system on the demo CD uses about 8 files and is rather complex; however, it is a robust model.  I recommend reading about it, then implementing a simpler and scaled down version if that is all you need.

The topic of building a login system is too long to write about here.  However, the main idea is to get the user to enter a name and password which you check against user data stored in the database.

For now I'm going to assume you've logged the user in and have captured that employee's ID in a global key field, keyg_employeeID.  I'm also going to assume that in your file you have a key field named keyf_employeeID, which marks that record as belonging to a particular employee.

Given that, you can set a password privilege that only allows the user to browse his/her own record.  You can set the password privileges by going to "File > Access Privileges > Passwords...".  

Under "Browse records:" choose "Limited".  In the calculation, enter "keyg_employeeID = keyf_employeeID".  Make the same entry under "Delete records:".  This now prevents the user from browsing or deleting any records that don't have their ID in the keyf_employeeID field.  If the user performs a find, the results will be filtered to only show those records that the logged in user has access to view.  You'll have to repeat for every table (file) in your solution.

There are other ways to do this, perhaps more elegantly; but this is the easiest, fastest, and most secure way to implement it.  An alternative method would be to script every action in the user interface (omit, delete, find, etc.) so that the scripts always check and filter the record set.  This can have advantages, but is a massive undertaking.

-Mariano
0
 
LVL 3

Expert Comment

by:D0N
ID: 9722488
If you've got a relatively low number of users, for a much simpler approach, you may want to explore the possibility of giving each each his/her own database.  This mechanism absolutely keeps the data separate and secure.  Of course, the manager would have access to them all and could combine them all for analysis/reports etc.
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
LVL 28

Expert Comment

by:lesouef
ID: 9723590
My way:
When the database is opened, I ask a login/passwd to user.
The users's name is stored in a global field.
Then you disable manual menu edition in the passwd parameters.
Do a script for new records and insert the users's name automatically.
Do a script for 'find' and 'find all' which automatically appends the users's name to the find conditions before executing the find operation.
0
 
LVL 3

Expert Comment

by:Mariano_Peterson
ID: 9723591
D0N has a good idea, but it brings up certain important drawbacks.  

Distributing seperate files to each user will significantly reduce the scalability of your solution - that is, it won't grow as your user base grows.
You'll have to worry about synchronization issues.  If each user has his/her own set of files, they won't be able to see the data on another user's database (they'll be on an isolated on a data island).
You'll also have to address file confusion issues.  If there are multiple copies of the a file with the same name on a network, FileMaker can get confused under certain specific circumstances and actually open and use one of the other files.  The best bet around this would be to rename the files specific to each user.  However, renaming files also opens up another can of worms.  If you're working with FileMaker Developer renaming files is a simple matter.  If you're using standard FileMaker Pro, you should not rename your files if you can at all avoid it.

-Mariano
0
 
LVL 3

Accepted Solution

by:
Mariano_Peterson earned 25 total points
ID: 9727697
There is no script you can write that will limit the user to only view their own records.  

What you desire reaches much beyond a single script and is better described as a methodology, something to be considered during the architectural design stage of your application.  This must be implemented through a series of scripts, layouts, fields, tables, and passwords.

Again, Chris Moyer and Bob Bower's book, "Advanced FileMaker Pro 5.5 Techniques for Developers", has a chapter or two devoted to database security.  I highly recommend you read so that you have a better ideas as to what is involved.

-Mariano
0
 

Author Comment

by:treynathan
ID: 9728365
thanks.. let me try all and shall get back to you guys very soon. mariono's suggestion sounds more familiar. Ron's can be tried too as i have relatively low number of users ( 9 users )
0
 

Author Comment

by:treynathan
ID: 9784152
I used mariono's method.. it worked fine.. but now i have multiuser access problem.. i created a stand alone database (deploy) using filemaker developer tool and shared it over the network. It can be accessed from the user's own desktop via shortcut created from the database workstation. Only one user can access to the database at a time.. i've already set the file sharing to multiuser but a message keep showing up telling me that it is a single user file. However, the fp5 files can be accessed by multiuser over the network. help!
0
 
LVL 28

Expert Comment

by:lesouef
ID: 9785633
This a one of the limits of FM runtimes, single user at a time, and cannot open files shared by a FM server, can only import files.
So, I am afraid you need you need FM server.
However, you could use another engine so store data, and use ODBC for instance to access data from a runtime. Not very handy. If you use an external plug-in for SQL operations, you must check if it is compatible with the runtime solution, some don't. I guess you do not want to get involved in this now, so I think the FM server would be the best. No dev is required. Your existing files can be used "as is" by a FM server. And you can test it, they have a 30 days trial version fully operationnal.
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Pop up windows can be a useful feature of any Filemaker database.  Though best used sparingly, they can be employed in a multitude of different ways, for example;  as a splash screen at login, during scripted processes to control user input, as pick…
Having just upgraded from Filemaker 11 to Filemaker 12 over the weekend, we thought we would add some tips for others making the same move.  In general, our installation went without incident. Please note that this is not a replacement for Chapter 5…
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

759 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now