.Net ramblings
# Tuesday, 22 June 2004
Adventures with .NET smart clients, running with Local Intranet permissions

I had originally deployed an app with msi but the advantages of smart clients soon began to convince me to change my deployment model.

What you can and can't do in Local Intranet

As a smart client, the app is executed as http://myserver/exec/myApp.exe
This works very nicely, until those security exceptions start appearing.  I had to spend a long time going through my app to find out what was causing the exceptions.  The obvious reason for the exceptions is that programs coming in from the Intranet are less trusted than those on My Computer, and hence are subject to more restrictions by the local security policy.  After much exploration and reading up online, i found out some interesting facts:

  • you can't access Environment.Machinename
  • you can't access My Documents, or UserAppDataPath, etc.
  • you can't call abort() on a Thread, but you can call Sleep() and Start()
  • you can read files through openFileDialog
  • you can read and write to IsolatedStorage (a virtual file-system specially for your app), very useful seeing as you can't write to any physical location on the hard disk by default.
  • you can invoke delegates asynchronously

You could deduce these by looking in the .Net Framework Security Policy (control panel > admin tools > .Net Framework configuration > Runtime security policy > Machine > Permission Sets > Local Intranet), and then double click one of the items in the main pane to the right, to see what restrictions if any are applied for the selected zone.

I found out the above information hard way through trial and error, but it was a very valuable exercise to learn about the security policy.

Using a class library with your smart client app

I got a large part of my app working, but i was using a class library of customised windows forms components, and this was causing a security exception.  It took a few hours to pin down, but the docs finally revealed that the class library must have the following attribute (outside a class declaration):

[assembly:AllowPartiallyTrustedCallers] 

The app worked fine after I added that line.

Requesting permissions from the local Security Policy before your app runs. 

If you are not sure what zone your app will run in, you can request a minimum level which your app requires. Add the following line of code outside a class declaration in one of the files in your project:

[assembly:PermissionSetAttribute(SecurityAction.RequestMinimum, Name = "LocalIntranet")]

This will alert the user that they don't have permissions to run the app if it is running in a zone less than Local Intranet. 

Conclusion

I personally have found these bits of information very difficult to pull together.  There is a ton of stuff about smart clients but its mostly non-technical.  I even got a CD from msdn about smart clients and i found it useless for helping out with any of the problems i have encountered along the way.

I hear there is a tool called PermCalc.exe coming with Whidbey that will probe an app to see what would cause security problems in a smart client scenario but until then, we are stuck doing it manually :)


Tuesday, 22 June 2004 19:16:34 (GMT Daylight Time, UTC+01:00)  #    Comments [0]  .Net Windows Forms

OpenID
Please login with either your OpenID above, or your details below.
Name
E-mail
Home page

Comment (Some html is allowed: a@href@title, strike) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

[Captcha]Enter the code shown (prevents robots):

Live Comment Preview