Restricting OpenFileDialog operations.

  • Thread starter Thread starter Martin Hart Turner
  • Start date Start date
M

Martin Hart Turner

Hi:

What I want to do is launch an OpenFileDialog/SaveFileDialog so the user
can select a path/file. Once the user pushes 'OK' I'll do the work
behind the scenes of loading or saving the file.

What I don't want, is for the user to be able to delete or copy/cut
files/ folders, or do any drag & drop operations while they have the
OpenFileDialog o SaveFileDialog open.

Is this possible?

TIA,
MartinH.
 
This is definitely not possible via the functionality exposed by the managed
wrapper classes. It might be possible via customization of the dialogs
(http://msdn.microsoft.com/library/d...ommondialogboxes/openandsaveasdialogboxes.asp).
(BTW, I've never personally attempted the exact change you seem to want, so
I can't vouch that it's actually possible via file dialog customization.)

That said, it sounds to me like you might be barking up the wrong tree here.
Even if you can manage to tweak the dialog behaviour, there's presumably
nothing stopping the interactive user (or even another user with permissions
on the same set of directories and/or files) from modifying the target
directory contents while the user happens to be using the file dialog in
your application.

If the user shouldn't be able to modify the directory contents, his account
shouldn't have anything but read permissions on the directory and its
contents. If any account should be able to modify the directory contents,
then your application should probably be able to written to cope with any
changes that might occur between the opening of a file dialog and the app's
processing of any files selected in that dialog. If you're not sure what
would be the best approach in your application, perhaps you might be able to
describe why you're concerned about users making changes via the file
dialogs in the first place?
 
Nicole:

There is plenty of food for thought here, so let me explain what I'm
trying to achieve/restrict.

The program will be a .NET 2.0 WinForms application, using SQL Server
2005 as the database.

My program will be installed in a folder structure similar to this:
\\ServerName\SharedFolder\ProgramRoot

with the data in subdirectories like:
\\ServerName\SharedFolder\ProgramRoot\Company1
\\ServerName\SharedFolder\ProgramRoot\Company2
etc.

I will be using impersonation to run the program so I can restrict the
folders where the user can access via the OS, but the program can still
read/write/create/delete files in the restricted folders.

There are a few places in the program where I let the user select files
to open/save via the common dialogs (OpenFileDialog etc.) As the program
is running impersonating a higher level user, the user can access areas
where I *only* want them to pick a file, but *not*
copy/cut/delete/rename anything. This is where the restrictions come in.

Should I be looking for other solutions, or is this a valid scenario?

TIA,
MartinH.


Nicole Calinoiu escribió:
 
Your post brings up some good points. However, assuming that the requirement
is that an OpenFileDialog not be able to modify the directory contents,
another alternative would be for the OP to write a custom Control that looks
and behaves like an OpenFileDialog, but does not have the functionality to
modify the directory contents. This would not be too complicated to do.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.
 
Kevin:

I was thinking about this, and if I'm not barking up the wrong tree,
this is probably the way I'll go.

Thanks,
MartinH.

Kevin Spencer escribió:
 
In that case, creating your own read-only UI as Kevin suggested is probably
your best bet. To keep things as safe as possible, the UI itself should run
under the account of the interactive user, with only the file reading
operations running under the impersonated account.
 
That makes sense in light of what we know now. However, if the goal had
been to prevent modification of the directory contents for some sort of
internal consistency reasons, a custom UI wouldn't have been sufficient
since the directory contents could have been modified by an external
process.
 
Hi Nicole,

It makes sense if the requirements are what I supposed they might be.
Sometimes I can't see the logic of requirements, but sometimes requirements
are illogical, such as illogical requirements given by a client (I'm sure
we've all experienced this!). I just supplied information that might be
helpful if that was the case.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but you can't make it stink.
 
Nicole:

That make a lot of sense.

Thanks very much for your insight.

Regards,
MartinH.

Nicole Calinoiu escribió:
 
Back
Top