Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Stupid .net "security" trick?

According to:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q324565

use of the printing classes isn't supported when run as a service, which means it doesn't work when you try to print from an asp page.  OK, I can live with this, though it might be nice to mention this fact in the documentation.

However, can anyone come up with any rational explanation as to why it DOES work:

- when I access the page by hitting F-5 from VS 2003
- when I access the page via http://localhost/
- when I access the page via http://machinename/

To recap, I can use the printing classes in all 3 of the above scenarios, it's only when I try via http://machinename.domain.com that it throws the "Invalid Printer Exception".

Exception is coming from GetHdevmodeInternal()

Is this some sort of stupid security kludge to prevent a driver from affecting the web server?  Any rational explanation for why it works in some cases, but not others?

Chris F
Friday, April 15, 2005

I'm not sure I understand what you are doing with printing (client-side? server-side?) but, the .NET runtime assigns a more strict set of privileges to a process launched from a fully qualified domain name (machine.domian.com).

That could be the cause....

Jeff Mastry
Friday, April 15, 2005

I'm building an intranet app, and need to be able to print onto some pre-printed forms.

Originally, it was going to be a desktop app, but we're moving away from that where ever possible.  When I discovered that I could actually use the Printing classes from the server, we decided to try a web-based application.

It was only when I tried to set up a test on the dev server that I discovered that printing was "suddenly" disabled.

I don't suppose that you know of any documentation that details which classes are depreciated when accessed via a full-qualified hostname?

Chris F
Friday, April 15, 2005

> However, can anyone come up with any rational explanation as to why it DOES work

Here's a total guess:

* Services are priviledged and therefore vulnerable
* It's more dangerous to print something on the internet than to print something on your local machine (because stuff on the internet is more likely to be malicious)

Is there anything analagous to the 'security zones' which I can specify using Internet Explorer ... i.e. is there any way to say that domain.com is "trusted"?

Christopher Wells
Friday, April 15, 2005

I might believe that if it was throwing a security exeption...

Chris F
Friday, April 15, 2005

I'm not aware of any.

The MSDN docs give the required permissions for every (?)method. Unfortunately, it isn't always obvious how these permissions map to the Runtime Security Policy settings (in Control Panel).

Since this is an intranet app, can't your users use simple machine names? We do this, and we set "Local Intranet" to Full Trust - solves a lot of problems (from a developers perspective anyway :) ).

Jeff Mastry
Friday, April 15, 2005


When the URL has dots in the host part, or the host part is an IP address (any, even 127.0.0.1), your code is placed in the Internet code group. (Don't remember where it is docummented, but it is true).

Otherways, it is placed in the Intranet code group. You could modify code access security policy to allow the Internet code group to print.

You could also add the domain name of you application server to the trusted internet zone in Internet Explorer.

Anyway, you need to do some configuration in every client.

Why don't you provide a download instead?

.NET Developer
Friday, April 22, 2005

Are you saying that the security settings on a .NET *server* application are affected by the IE settings on a *client*?

Chris F
Tuesday, April 26, 2005

A client can limit what a server based application can do locally according to its own security settings (zones, code groups, etc...)

If a client runs a  server application from the Internet (for instance), it will be more restricted than if the same application was run from a local hard drive.

Here's a good starting point for Code Access Security:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcodeaccesssecurity.asp

Jeff Mastry
Monday, May 02, 2005

*  Recent Topics

*  Fog Creek Home