Jump to content

WebDirect Security Bug : Record-level view permissions default to True if Schema is being edited


xochi
 Share

This topic is 2841 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Remember how old IWP had a bad bug in which sometimes, if a user hit the Reload button on the web site, they'd drop back to Record 1 in the found set? I've found something similar in WebDirect.

 

  • If you have a table the table has Record-level permissions the permissions are set to a field calculation (for example, RecordVisible = If(Table::UserName == Get(CurrentAccountName) ; 1 ; 0)
  • And someone is editing the Schema on a live hosted database
  • Then A WebDirect user may get an error dialog "Database schema in use: the operation cannot be performed because another user is currently modifying the database schema.". (which is not unreasonable).
  • However, in addition: The WebDirect user will be dropped onto a record in the table, and that record will be completely visible to the user, regardless of the record-level calculations.

 

Note: I'm seeing this in FMS 13.0 v4 but haven't yet upgraded to 13.0 v5.

 

 

Discussion: I agree that editing a live filemaker database is not "best practice" but I also know many of us do it.

 

The main problem here is that WebDirect seems to have logic saying "If for some reason I can't tell if a record is supposed to be viewable, I'll just show it anyway". A much safer default would be "If anything does wrong in record visibility calculations, default to NO".

Link to comment
Share on other sites

Further info, I believe I can tell what's happening and trap it:

 

  • A script navigates to a layout.
  • Tries to create a New Record.
  • This fails with a 303 error (Schema in use)
  • Which leaves the WebDirect user positioned on an existing record.

 

What should happen:

  • The record should not be visible (due to record level security permissions)

 

What actually happens:

  • The record is visible, in spite of the record-level security permissions.

 

Fortunately the workaround is fairly easy:

New Record
If Get(LastError) <> 0 then
  exit the layout (or maybe Exit Application to be safe)
end if
Link to comment
Share on other sites

 

RecordVisible = If(Table::UserName == Get(CurrentAccountName) ; 1 ; 0)

 

What happens if you just change the RLA calculation to Exact (UserName; Get(AccountName))?

That will evaluate to either 1 or 0 and the RLA calculation will proceed from there?

 

Where did you find the function CurrentAccountName?

 

Steven

Link to comment
Share on other sites

What happens if you just change the RLA calculation to Exact (UserName; Get(AccountName))?

That will evaluate to either 1 or 0 and the RLA calculation will proceed from there?

 

Where did you find the function CurrentAccountName?

 

Steven

 

Sorry, I was using Get(AccountName) - just typed it incorrectly from memory.

 

I've done another test, in which I tried something simpler:

 

RecordVisible = 0

 

And yet the record still shows as visible after the 303 error happens.

Link to comment
Share on other sites

First, I'll upgrade to 13v5 since it sounds like there were some WebDirect fixes (though nothing specific about this issue).  

If it's still showing up there, I will see if i can reproduce this in a simple file and pass that on to FMI.

Link to comment
Share on other sites

I've done some more work on this and I can reproduce the problem in a simple test file:

  • The file has a record-level permission which sets a record to not visible after 1 minute.
  • The file has a script which runs with full access permissions, and creates a new record then navigates to another record.

After a few runs of the script, the record permissions start getting wacky.

Here's a copy of the database for test:

(account = admin password = admin)

Download: http://xochi.com/mike/fm/webdirect/RecordLevelBug/WDTest1.fmp12

And here's a screenshot of it malfunctioning:

WDTest1.png

You will notice two issues in this screenshot:

  • The user can see the value of Record 0001 "SSN" field
  • The user can see the entire value of Record 0006, even though the calc cRecordVisible is clearly set to zero.

I don't know, at the moment, what's causing this, but it's probably a combination of:

  • using a timestamp calculation in a record-level permission
  • using "Run script with full access privileges"
  • having the database schema / table editor open while a WebDirect script calls NewRecord
Link to comment
Share on other sites

Please post your file here.

 

It’s the same as attaching a screen shot, only it needs to be zipped. The steps how to do this is found here ATTACH A FILE

 

There are several reasons that we want the files posted here, some of them are because, links get broken, links can be spam, the files get removed after the OP gets their solution, etc., Because this is is a learning Forum, often a solution that works for one member can be the answer another member needs. Without the demo file, there is a hole in the process.

 

 

Lee

Link to comment
Share on other sites

This topic is 2841 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.