Restrict Login to Specific Account

[Agentshevy]

My solution has a staff layout. How can I limit each user who happens to be a staff, to his/her own staff page. ie when a staff (user) logs in to the database, he/she is redirected to his own page (staff layout).

 

the essence is just for Staff to have NO access to the records of each other. I have hidden the tool bar so as not to allow ''Go go Next Record'' navigation. I don't really know if my topic rightly suggests my intention for this post, but I am hoping you get my point. Thanks

[john renfrew]

Look at stuff on the session model.

 

Todd has a great video here

https://www.geistinteractive.com/2014/12/10/filemaker-session-model-video/

[Wim Decorte]

Also look at the native security functions in FM: Record Level Access.  Anything you do to stray away from that is going to compromise security.

[Steven H. Blackwell]

Pay attention to what Wim said.  

 

Hiding the toolbar will not prevent record to record navigation.

 

The system needed here is called Record Level Access.  It is invoked by use of the custom Privilege Set options found in the Manage Security section of the file.  Additionally you need to restrict external access to the file.

 

These are some of the very issues I will be discussing at the Developer Conference this summer. 

http://www.filemaker.com/learning/devcon/2015/schedule-wednesday.html#COR011

 

Steven

[Agentshevy]

Also look at the native security functions in FM: Record Level Access.  Anything you do to stray away from that is going to compromise security.

Thanks for your reply. Please, where can I read up this Record Level Access and how to implement it?

[bcooney]

Shevy,

All of the above still applies. However, what you may want is to include a field in your staff table that contains the accountname. In a script that runs OnFirstWindowOpen, you can go to your Staff layout, and perform a find for staff::account name = Get (account name). That will leave your user on "their" staff record. From there, you would use RLA with tight navigation to limit their world, so to speak.

hth,

Barbara 

[comment]

How can I limit each user who happens to be a staff, to his/her own staff page. ie when a staff (user) logs in to the database, he/she is redirected to his own page (staff layout).

 

Those are two separate requirements:

 

1. To prevent staff from accessing records other than their own, define their privilege set to allow them access to records in the Staff table only when:

Staff::AccountName = Get ( AccountName )

2. Once you have that set up correctly, you can perform a find as part of the startup script. Note that any find will automatically omit records to which the current user has no access. The important thing to remember is that omitting the other records is just cosmetics; the real security comes from the privilege set. Even if they manage somehow to navigate to another record, all they will see is some <no access> labels.

[Wim Decorte]

Keep in mind that if External Authentication is in play, a user may be logging in with different formats of their account name:

 

- username

- DOMAINusername

- username@domain

 

The FM Get(Accountname) will faithfully return what the user used but it may not be what they used the last time.  So make sure to check for that and parse out what the real account name is.

[Steven H. Blackwell]

 

In a script that runs OnFirstWindowOpen, you can go to your Staff layout, and perform a find for staff::account name = Get (account name).

 

Suppose I can open the file and bypass this Opening Script?  What then?  The UI and Business Logic are not part of the security schema.  That's why Record Level Access is critical.

 

A general find performed on a set of records based on some criterion will omit from the resulting found set those records blocked by RLA from the Active Account's user.

 

Barbara's process will work to isolate records.  But I wanted to be sure to note that on Open Scripts are not reliable for security purposes.

 

Steven

[bruceR]

I suspect simple example files would be enormously useful.

[Agentshevy]

thanks all for your contributions.. I am begining to understand to some little extent.. Your suggestions have all been helpful..

Like Bruce suggested, a sample file of these suggestions would go a long way to help.. (from a beginner perspective)

[Agentshevy]

like bcooney and Coment suggested.. Using this to restrict access..

Staff::AccountName

= Get ( AccountName

)

please, can I use staff_ID instead of Account name? If yes, how can I go about it, because I have tried

Staff::Staff_ID = Get (Staff::Staff_ID)

And I wasnt successful..

[Agentshevy]

the challenge I am having for not using

Staff::AccountName

= Get ( AccountName

)

is that a staff should only have one record on the staff table.. That should be his profile page. But from the way i see it, a staff can create as many records as he wants, thus giving him access to all those records he created..

Is there any way to limit access to just one record per staff on the staff table?

[Wim Decorte]

The easiest way to do that is to change the privilege set for the users to not be able to create records.  If a record needs to be created, do it through a script that you control.

[bcooney]

Shevy,

You have two jobs. Navigation and record level access (security). They complement each other. Tight navigation does not equal good security.

 

I had suggested that you find in the staff table using Get (AccountName) = Staff::AccountName. That "lands" them on their Staff record (that you wish to serve as their landing page on login). Now your job is to limit what buttons they have access to on that Staff layout. If you are not hiding the Status Bar (which is what I do), then they have access to the New Record button. As Wim suggested, use a Security rule to not allow create in the Staff table for that account's privilege set. I would hide the status bar and create a New Staff Record button that uses Hide When Get(AccountPrivilegeSetName) <> the priv set allowed to create new staff records.

[Agentshevy]

create a New Staff Record button that uses Hide When Get(AccountPrivilegeSetName) <> the priv set allowed to create new staff records.

Thanks for your reply. Please can You elaborate more on this? I have restricted access to record creation on the staff table for the priviledgeset called STAFF, how do I create the script for the New Staff Record button? what script steps are involved especially where you said

"the priv set allowed to create new staff records"

 

and can you explain what the button does actually? I am guessing that the button would be visible to ONLY a staff who DOES NOT have a record on the staff table..

[Agentshevy]

The easiest way to do that is to change the privilege set for the users to not be able to create records.  If a record needs to be created, do it through a script that you control.

Thanks for your reply.. Looks like your suggestion is in line with bcooney's .. but then creating a script for that purpose is now the challenge. What script steps am I gonna use for this script? I am guessing this will be placed as NEW STAFF button on the layout.

[bcooney]

Shevy,

 

Where are you going with this, btw? What is your overall navigation design? Knowing this is important. I am assuming that you plan to have a user's staff record be their "Home" page, and all functionality available to them starts there. Is this a fair assumption?

 

I have led you astray on the New Staff button. I keep forgetting that you do not need to block access via script, since in FM13 you can hide the button! So, your New Staff button script does not need to ascertain if the current priv set is allowed to click the button -- only those allowed will SEE it! Right? That's what you're doing?

 

What are your defined priv sets?

 

Here's what I had in mind (see attached demo, full access account is admin with no password)

staff.fmp12.zip

[Agentshevy]

thanks a million, bcooney.. Your sample file explained everything... It has even given me alot more possibilities that I can achieve.. Thanks again..