Drag and drop file uploads in IE with .NET

I've received a couple of requests lately about how to implement drag-and-drop multiple file uploads in Internet Explorer from within managed code. Fortunately for me, someone else has already taken the liberty of writing an article on the subject at large: Host Secure, Lightweight Client-Side Controls in Microsoft Internet Explorer. Just a couple of tweaks and it'll be accepting files via drag and drop too.

In MultiUploadCtrl.cs, we need to enable drag and drop processing in the user control. Setting AllowDrop=True handles that in one swoop, now all that's left is the plumbing to handle the dropped files. For the events, DragEnter and DragDrop, the following should work well:

private

void MultiUploadCtrl_DragEnter(object sender, System.Windows.Forms.DragEventArgs e)
{
  if (e.Data.GetDataPresent("FileDrop"))
e.Effect = DragDropEffects.Copy;
  else
    e.Effect = DragDropEffects.None;
}

private void MultiUploadCtrl_DragDrop(object sender, System.Windows.Forms.DragEventArgs e)
{
  new FileIOPermission(PermissionState.Unrestricted).Assert();
  foreach (string fileListItem in (e.Data.GetData("FileDrop") as string[]))
{
    if (!fileTable.Contains(fileListItem))
{
AddFile(fileListItem);
}
}
CodeAccessPermission.RevertAssert();
UpdateFileSizeDescription();
}

Comments

• Anonymous
  February 16, 2004
  And as soon as somebody installs this you can use it to lift files from their system without them even knowing (just call AddFile with as many files you need and submit a form, no user interaction required).
  
  I would expect Microsoft employees to be a little more responsible when posting deliberate security holes on the internet.
• Anonymous
  February 16, 2004
  A good point that would be true in the ActiveX world without other considerations.
  
  The column does speak to this problem in the 'New Security Model' section. The standard permission set for controls loaded in the Internet zone won't allow for arbitrary file system access, it has to be explicitly granted through the configuration tool (or a setup package) and even then is subject to the hierarchy of enterprise, machine and user settings.
  
  Extending this sample, additional steps along the lines of
  a) checking FileUploadURL ('site-locking' so uploads can only go to the site the user expects them to)
  and
  b) explicitly prompting the user with the list of files before uploading
  could also be used to good effect.
• Anonymous
  February 16, 2004
  The problem with security is that users who will have a valid use for this will allow it to run and access the file system without restrictions (being able to specify a restricted access, such as read-only and only within current user's profile/my documents would help a little too).
  
  Prompting the user is probably the only way to prevent mis-using this, because when would you check the action url? You can attach an event handler to submit event and change it there, from legit to a rogue one.
  
  As for calling AddFile - you can hide it, making it inaccessible to a script in a page, but any script will be able to craft an event object and call your event handler, making it just a little more difficult to misuse but not fixing the problem.
  
  Maybe Secure computing initiative should also apply to examples posted on MSDN :)
• Anonymous
  February 16, 2004
  Dude, calm down. If you don't like it, don't deploy it. I think this sort of control is intended for use in an Intranet environment. The question was HOW to do this, not WHAT are the reasons not to.
  
  MG2.0
• Anonymous
  February 17, 2004
  The comment has been removed
• Anonymous
  February 17, 2004
  The comment has been removed
• Anonymous
  February 17, 2004
  I don't remember if the article explicitly mentions this, but have you copied the generated assembly (bindebugupload.dll) into the ServerFileUpload folder in your wwwroot? A blank frame suggests the browser is unable to retrive the assembly from the server. This post http://blogs.msdn.com/aoakley/archive/2003/06/20/49627.aspx has some pointers for further debugging.
  
  Regarding Workspaces, the permissions are granted as part of the installation package along with a few other checks. The installation package has a custom install action (extending System.Configuration.Install.Installer) that creates the code groups and permissions sets (see System.Security.Policy and System.Security.Permissions) before using System.Security.SecurityManager to save the modified policy.
• Anonymous
  February 17, 2004
  The comment has been removed
• Anonymous
  March 05, 2004
  I got a problem when set control's allowdrop = true. If I did that, the control itself can not been shown in Internet Explorer properly, which looks like un-open image, any helps?
  
  Many thanks