What could prevent a user from downloading a .NET assembly embedded in a web page?

[Queez]

I have a .NET assembly (ScanControl.dl l), which accesses a scanner on my client's local machine and allows them to scan a page (Scan()).

I have an ASP.NET web application with a page which will (theoretically) use this control to allow a user to scan a page into my database (Scan.aspx).

I serve the control as an object on the page, like so:

<object id="scanningObj" height="300px" width="500px" classid="ScanControl.dll#ScanControl"></object>

The ScanControl is a .NET assembly, so I have to strong sign it and add some stuff into the .NET configuration to allow it to run, but in general, when I view the page on my dev machine or on any clean machine in my office or any clean virtual machine anywhere, or any of the office laptops, the thing works and I can interface to my scanner and scan a page. However, the exact same code doesn't work on my customer's client machine.

The customer has their own server on which they run the server-side stuff, so the web app is running under local intranet at both locations.

Some further investigation on a couple of their machines identifies that the ScanControl.dll is not being downloaded from the web page. I can use gacutil.exe to discover this:

gacutil.exe /ldl

This is different to the behaviour on my machine, where the control is definitely being downloaded.

So my question is: Does anyone know of some security policy or some firewall/proxy server/IE settings that might prevent their browser from downloading the DLL? I thought I'd have problems running the downloaded DLL, but I never thought I'd have problems downloading it in the first place!

Eagerly awaiting your replies =)

[Plater]

I can think of a few reasons I think:

• The .NET framework has it's own set of security settings which can be found under administrator tools. There could be a setting in there restricting you.
  
• As I understand it FF doesn't *do* activeX objects, so you could be getting blocked there.
  
• IE I think has defaults in it's own security zone to not download activeX content or do any other scripting. I think newer versions of IE also have settings just for .NET objects. Something there could be blocking you?

[Queez]

I can think of a few reasons I think:

• The .NET framework has it's own set of security settings which can be found under administrator tools. There could be a setting in there restricting you.
  
• As I understand it FF doesn't *do* activeX objects, so you could be getting blocked there.
  
• IE I think has defaults in it's own security zone to not download activeX content or do any other scripting. I think newer versions of IE also have settings just for .NET objects. Something there could be blocking you?

Plater, thanks for your reply. I am aware of the .NET Framework security settings, so I have an MSI which is rolled out to each client machine. The MSI, when run, sets up the .NET security settings on that machine to allow my particular signed assembly to run under "Full Trust", so that shouldn't be a problem.

The client machines only have IE, never Firefox or any other browser, so that's not an issue.

In terms of IE security, we have tried putting the website into the "Trusted Sites" zone, and we've manually set the applicable settings under "Security" to "Enable", but this doesn't help. Granted, this is where I would expect to see the issue, as IE would have specific control over what is downloaded. The .NET Framework security settings are more to do with what can be RUN on the local machine, rather than what can be downloaded.

The settings in IE that I note with particular interest are: ".NET Framework" and ".NET Framework-reliant components". The object is not an ActiveX control, so the ActiveX settings should not have any affect on this problem (it's a .NET assembly).

Thanks again for your help. Please correct me if I am wrong in anything I've said. What about Group Policy or some kind of network security policy? Is it possible there is something on the domain that could stop clients downloading the object via the web?

[Plater]

Well I *think* .NET objects that have to be downloaded still fall under "activex restriction" settings, even though they don't use traditional COM methods of being created.
I am not sure though, the .NET assemblies were always a little funky when I tried to use them. I kept having to flush my global cache anytime there was change to the assembly.

[Frinavale]

Why not just have them scan the files in on their own and give them an Upload option on your web page that lets them upload the files they've scanned?

[Queez]

Hey man, you were right.

I've done a full experiment to try and determine if any of the IE settings would affect the way the assembly is downloaded or run, and it turns out .NET assemblies can be prevented from being downloaded using the ActiveX security settings.

Interestingly, the final solution is to ensure the following setting is switched on:

NET Framework-reliant components

Run components not signed with Authenticode

We have now signed our component with a digital certificate, so hopefully (hopefully) it will not cause a problem on the customer's network.

Having said that, I believe they have a group policy set up on their network to keep this setting switched off, regardless of what the user switches it to, but hopefully a signed assembly will be more likely to get through than an unsigned one!

-Q

[Queez]

Why not just have them scan the files in on their own and give them an Upload option on your web page that lets them upload the files they've scanned?

Thanks Frinavale. That's another option for the user that we've already implemented, but the product has to be able to do everything the thick-client predecessor was able to do (one of which was interface directly with their scanner), so we have to be able to offer both options.

Thankfully, the upload system is working fine, so the customer is currently using that option as a workaround until this scanning stuff is sorted!

Thanks again

-Q

[Frinavale]

Thanks Frinavale. That's another option for the user that we've already implemented, but the product has to be able to do everything the thick-client predecessor was able to do (one of which was interface directly with their scanner), so we have to be able to offer both options.

Thankfully, the upload system is working fine, so the customer is currently using that option as a workaround until this scanning stuff is sorted!

Thanks again

-Q

One thing that I've been finding is that users expect web applications to be as rich as the desktop applications twin. Sometimes this really makes a developer's life difficult.


One option I would look into is ether creating or using a "true" ActiveX control that access the scanner instead of using .NET assemblies. There are a lot of .NET security features that could block the user from using the assembly and if their machine isn't configured perfectly there will be problems.

Good luck to you.

[Queez]

One option I would look into is ether creating or using a "true" ActiveX control that access the scanner instead of using .NET assemblies. There are a lot of .NET security features that could block the user from using the assembly and if their machine isn't configured perfectly there will be problems.

Am I right in thinking that ActiveX controls cannot be written in .NET? I have a feeling my company is trying to move forward with new technology (at any cost...), so this idea would not go down well with them! Surely there must be a way of doing this without using ActiveX controls?

[Plater]

Am I right in thinking that ActiveX controls cannot be written in .NET? I have a feeling my company is trying to move forward with new technology (at any cost...), so this idea would not go down well with them! Surely there must be a way of doing this without using ActiveX controls?

I would say that yes, .NET would not make 'true' activeX controls.
You could try java maybe?

[Frinavale]

I would say that yes, .NET would not make 'true' activeX controls.
You could try java maybe?

.NET cannot make "true" ActiveX controls.

You can develop ActiveX controls in C, C++, Visual Basic, and Java but not managed .NET code (well you can but they aren't quite the same). ActiveX controls have full access to the Windows operating system and what makes them a little suspicious is that they can be automatically downloaded and executed by Internet Explorer.

[Queez]

ActiveX controls have full access to the Windows operating system and what makes them a little suspicious is that they can be automatically downloaded and executed by Internet Explorer.

For anyone who's still interested, we have managed to find a way around this problem.

Basically, there is a way to mark a .NET object as "safe for scripting" via the registry. We looked into implementing IObjectSafety, but because this is a legacy VB5/VB6, this didn't seem to work on our .NET assembly (although we found that solution on the internet somewhere and it seemed to have worked for others).

However, if you register the following keys, based on the GUID of your assembly, this effectively marks it safe for scripting. The nice thing about this solution is we don't have to change our code. It also means you can't mark .NET assemblies safe for scripting from the web (easily), but you can do it if you're installing it manually on the client, and you have the right permissions (which is what we need!).

The registry keys are:

[HKEY_LOCAL_MACH INE\SOFTWARE\Cl asses\CLSID\[your assembly's GUID]\Implemented Categories\{7DD 95801-9882-11CF-9FA9-00AA006C42C4}]

[HKEY_LOCAL_MACH INE\SOFTWARE\Cl asses\CLSID\[your assembly's GUID]\Implemented Categories\{7DD 95802-9882-11CF-9FA9-00AA006C42C4}]

Adding those (either manually, through a .reg file, or automatically using an MSI or other installer) will mark your assembly safe for scripting!

Cheers

-Q

[Frinavale]

Thanks a lot!

I'll have to give that a try some time :)