Restricting direct access (Data Separation)

[Hurican]

I am using what could be loosely called the Data Separation model.

This is not a file that will be served or published to the web, it will be compiled into a runtime eventually.

I have the "Main Menu" file in the main directory, another database in it's own directory which holds account, and registration information, and a third directory which holds all of the files.

I would like to be able to restrict access to the Files, and the Accounts database, so users can only open it through the Main menu. I know it cannot be that difficult but it's something I'm missing.

Ideas, or something to point me in the right direction would be greatly appreciated.

[Steven H. Blackwell]

Whatever this construct is, it is not The Separation Model as that term is correctly understood.

When you say "...restrict access..." what do you mean exactly? If this file is on the user's desktop, the user has physical access to it. If, OTOH, you want to control the ability of a user to see the information within tables from the UI of that specific file then the Privilege Set is the tool to use.

HTH

Steven

[Hurican]

If set on the desktop, then the only file visible would be the Menu file. In accompanying folders, there are the user files, and in a separate folder, the file that contains security information. The data exists separately in a data folder to be imported dynamically depending on which file is chosen. Yeah I know it is a weird solution, :-) it is based upon a dynamic templating system.

I want the users to only be able to access the files via the Menu file, if they should happen to go into one of the folders directly, to disallow access and take them back to the menu file.

[Hurican]

" Whatever this construct is, it is not The Separation Model as that term is correctly understood.

When you say "...restrict access..." what do you mean exactly? "

You're right. This is not really a separation model in the true sense of the term. I should have not used that terminology.

By restricting Access, I mean if the user clicks on the file directly, they will not be able to open it at all.

[Steven H. Blackwell]

By restricting Access, I mean if the user clicks on the file directly, they will not be able to open it at all.

I doubt this is achievable, but let me think about it some. The problem with the obvious answer of setting a startup script in that file to do something to control the process is that that script might well be triggered at other undesired times and locations.

Steven

[Hurican]

I am making progress. The startup script in the Menu file sets a "AccessSwitch" in the file that holds the account information which is related to all other files using a cartesian join.

Depending on Account accept or deny arguments in the Menu file, this switch is set to "on" or "off" or "" (removing values at close of file). There a separate startup script in each of the user files wich looks at this value to determine how it will open. I think a variable would work (provided a local variable can be seen through a relationship, as long as the particular script is active... I have to check that out).

But essentially, the field is only switched "on" for the menu script, which is cleared after the file is opened. A logistical nightmare to be sure, but a cool challenge.

Thanks for your help.

[Steven H. Blackwell]

OK, just know that these startups can bre rather easily overridden.

Steven

[Hurican]

Luckily I don't needs AES level security for this file. , but I would like to know. What are some of the ways that you've seen in which startup scripts can be broken into?

[Steven H. Blackwell]

What are some of the ways that you've seen in which startup scripts can be broken into?

There are, I believe, over a dozen documented ways. Two of the more common ways are to run another script in the file which will cause it to open without the opening script's running and to turn on the debugger and stop the script after its first step.

Steven