Re: Restricting OpenFileDialog operations.

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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.


"Martin Hart Turner" <"martin _dot_ hartturner _at_ gmail.com"> wrote in
message news:et3J52O%23FHA.1032@xxxxxxxxxxxxxxxxxxxxxxx
> 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ó:
>> 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/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/commondialogboxlibrary/aboutcommondialogboxes/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?
>>
>>
>>
>> "Martin Hart Turner" <"martin _dot_ hartturner _at_ gmail.com"> wrote in
>> message news:%23NpYJOM%23FHA.2036@xxxxxxxxxxxxxxxxxxxxxxx
>>> 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.
>>

.

Relevant Pages

  • Re: Restricting OpenFileDialog operations.
    ... 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* ... If the user shouldn't be able to modify the directory contents, his account ...
    (microsoft.public.dotnet.framework)
  • Re: SetPassword access denied
    ... safely invoke SetPassword etc..... ... impersonation or using the process token without impersonation) is NOT ... account that is used for performing remote activities in the directory. ... Co-author of "The .NET Developer's Guide to Directory Services ...
    (microsoft.public.windows.server.active_directory)
  • Re: VS.NET 2005 and the "allowDefinition=MachineToApplication" error
    ... Your description of impersonation is great. ... If you want to use the default configured account, eliminate that entry, or configure it as: ... The easiest way to assign correct permissions to all required directories is to run: ... I re-started IIS and tried to access my ASPX page again -- same ...
    (microsoft.public.dotnet.framework.aspnet)
  • [Full-disclosure] Maybe nothing so shady; depends on the motive.
    ... There may be no impersonation going on. ... attempted use of a disabled account would produce messages about "account foo login fail" ... SecureWorks was still reading email addressed to David Maynor. ...
    (Full-Disclosure)
  • Re: Impersonation
    ... impersonation, unless you actually need to be userX for some file operation, ... I also wonder why folks always talk about using a seperate account DB. ... I know the diference between IIS and WSE authentication mecanism. ... >>> where I need to check password in UsernameTokenManager for that I need ...
    (microsoft.public.dotnet.framework.webservices.enhancements)