Thanks, we will study.
>>We have had some interesting security concerns come up from our clients recently. We run with a VFP backend and in one case we had a client delete a folder with all of our data files. We have also had Auditors cite our clients because of the ease at modifying dbf files. Any thoughts on how to improve file security (short of going to SQL server, I'm too old for that)?
>
>You are not really giving us a lot of details to work from - so I will assume Windows for both Client and Server with LAN access only - i.e. no WAN bottlenecks. You have several options to make it less easy for Users to accidentally damage / access your tables directly. In increasing order of difficulty / cost:
- Change the data folder attribute to Hidden.
- Change the extension of DBF’s so that they are less likely to be recognized by Windows Explorer. This will require that you change your open table code (which should be a single generic routine).
- Do not rely on a mapped drive use UNC’s instead
> e.g. USE M:\Data\TableName.Sy1
> becomes USE \\ServerName\ShareName\Data\TableName.Sy1 (this should be in VFP's path). - Change your presentation layer so that all data access is done through a COM object (also written in VFP) the COM object is configured to Run As a specific User that has access to the relevant folder, the User instantiating the object has permission to do that, but does not have direct access to the relevant folder.
- In conjunction with any of the above – encrypt data within the table. This could be restricted to those fields that a User could read and understand i.e. you probably will not gain much by encrypting primary keys if they are integers.
- And this is just a guess, but if you change access so that the Application is run via Terminal Services, I'd bet that opens up some security options.
