0

We want to be able to offer users of our software the facility of having a miscellaneous folder for each of their clients.

All these client folders would be stored together in another folder called 'miscellaneous data' for example

It would be accessible via an icon in the client record window in our software and would be a place to just drop files that aren't catered for by us.

A really simple solution is just to do a Shell call to explorer.exe with the folder address.

All the files would have the correct icons and look familiar and the user would be able to open them with their default programs

The problem with this is that this then allows the user to use file explorer to navigate up to the 'miscellaneous data' folder and possibly do something unintentional like delete a bunch of client folders.

I'd be very grateful for suggestions for a simple but more secure design

  • this is an IT networking issue and has little to do with the software program you are developing. Either your client sets up their network with the correct user permissions or they don't. There is little you can do from an application design perspective to enforce that. – Reactgular May 31 '13 at 17:23
  • The standard Windows 'Application Data' path is where these kinds of files are typically stored. Its not generally browsable by the user. – GrandmasterB May 31 '13 at 17:48
  • @GrandmasterB It's browsable if they can shell any folder under programdata. Our application would be exposing every other application's data – kjack May 31 '13 at 19:44
3

The problem with this is that this then allows the user to use file explorer to navigate up to the 'miscellaneous data' folder and possibly do something unintentional like delete a bunch of client folders.

That's what happens. Your user's hard drive could also crash, or they could open up %ProgramFiles% or %SystemRoot%and just start deleting.

If a hidden folder in %AppData% doesn't fit your needs, consider storing the information in a local SQL Server database, an application-managed file archive (Zip or Cap or whatnot), or some other container that sits as a single file on the drive.

If you really want it to be user-proof, you'll need something running with a distinct user account that writes to a folder accessible only to that account. A background service would be appropriate. (And, honestly, this is what you'd be doing with SQL Server.)

| improve this answer | |
  • Point taken, I think. BTW I don't think the hidden data approach helps at all because once they shell a folder under programdata the user can see the programdata folder hierarchy in the breadcrumbs and go wherever they want. It would be irresponsible to facilitate that. – kjack May 31 '13 at 19:42
0

Don't give a user's clients (a 3rd party) direct access to the user's file system. Just don't do it, even if the user -thinks- it might be ok.

Give these 3rd party users delegated access. Let the 3rd party upload files to a file processor with restricted but adequate privileges to read and write from 'safe' location. The processor might perform some filtering by document type, size, age, and context (if the 3rd party didn't upload it, they can't read it back for example; or if the 3rd party's IP address or subnet mask isn't known and whitelisted; or whatever other protections might be relevant) before allowing the activity.

For the user, they can access the file system normally, or they may have and use a 'safe' interface that provides some auxiliary auditing beyond any OS based auditing.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.