Security-related question/Setup Schema in WebDirect

[Rich S]

Greets, all:

I have a standalone, WebDirect-accessible file on our (hosted) FM Server (v19.x)  that's a form for users to use to update their personnel records; their e-mail address is a key that's related to another file that stores all the employee information; all the fields are foreign save for the E-mail Address field. (See attachment.) Currently, there's only one record in the database.

My question is, what happens if two people log in and want to access the form? Will the second person be locked out of the form while the first person is using it? Will the second person see what the first person has entered until the first user quits/logs out? What should the schema be for multiple users accessing the same file but its form is "free and clear" for each user that's signed on? Do I create, say twenty records then a startup script loops through something like Get(RecordOpenState) to see which record is available for use, then park them on that record, or...?

 

TIA for your help!

Rich

[comment]

1. How do they login?

2. Is the email field global?

 

[Rich S]

1. We're going to set it up so they log in through ADFS.

2. No, it's local. My thinking is that if it were global then everybody could see it. Am I wrong?

[comment]

5 hours ago, WF7A said:

My thinking is that if it were global then everybody could see it.

Actually, the opposite is true. The term "global" is a bit misleading. Each user (or more precisely, each session) has their own set of values in global fields. The fields are "global" in the sense that they do not belong to any specific record.

Now, the scenario you propose has a number of serious issues. If you use only one record, then any new user that logs in can see the existing user's data and may be prevented from entering their own data until the other user commits the record and releases it. There are some nuances depending on whether the field is global or not - but I want to skip all that because you have a much more critical issue here: e-mail addresses are not secret. Even if there were no security and/or record-locking problems caused by simultaneous login,  it would still be possible for a malicious user to enter another user's e-mail and view their data as well as modify it.

I am not sure why you want to use this two-file approach, but if you do, I would suggest creating a new record for each user as they log in, populating a global field with their account name and using this field as the key to the other file. You can delete this record  on log out.

 

[Rich S]

Thanks for the education about global fields.

My thinking about using a two-file approach is it adds an extra layer of security, but I can certainly set the security parameters in the "master" file so that connecting users are severely limited as to where they can go and what they can do. Would that be "better case"? I imagine I could use Get(AccountName) to automatically pull up their record (and hide the navigation controls) so they land on _only_ their record.

One edit: Since they're authenticated using ADFS, I can skip using their e-mail addy as an identifier/key.

Edited January 19, 2022 by WF7A

[comment]

I am afraid I don't know enough about your situation. I tend to think that restricting their privileges in the actual file so that they can only view and edit their own record (based on account name) would be simpler and quite sufficient. Note that performing ANY find will automatically omit any records which they are not allowed to view. For good measure, you should also make the Show All Records command unavailable - but even if you don't, the worst thing that can happen that they will see a bunch of records with [No Access] plastered over all fields.