«

»

Oct 01

Build security into your systems part 6

5. Be extra vigilant with any online activities, exiting fully when finished.  Otheerwise, the connection to the database may still be active.   Data may be accessible to other web users, or users might be prevented from accessing the file because the system considers it to be still in use.
In addition, web users should quit the browser to clear the account information from the web browser cache file to make sure it is not accessible to anyone who might use the computer afterwards.
6. Suppress the filenames of any files you don’t wish to have accessed via the database home page. This feature should not replace defining accounts and privileges in files.
7. Consider the results of scripts.
•If a script includes a step to delete records, and a web user opens the file with an account that doesn’t allow record deletion, the step to delete records won’t be executed.
However, the script might continue to run, which could lead to unexpected results. Consider enabling Run script with full access privileges to allow scripts to delete records or perform other restricted actions that users normally don’t have access to with accounts and privileges.
You can also restrict users from executing a specific script by modifying their privilege set and specifying scripts that have No access for particular users.
•Databases published on the web should include scripts that have no harmful effects if they are executed by any web user. To see script steps that are not supported, open the script and select the Indicate web compatibility checkbox. Dimmed script steps are not supported on the web. Also keep in mind that different scripts are supported by different browsers, and on different platforms, Mac vs Pc.
•If your scripts contain steps that are unsupported, for example, steps that are not web-compatible like Send Mail, or that users don’t have privileges to execute, use the Abort script feature to determine how subsequent steps are handled.

Leave a Reply