Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

Medium Trust - WebPermissions and SmtpPermissions


:P
On this page:

I’ve been going over some final code tweaks to my West Wind Web Store for a new release and one thing I’ve been fretting over is a couple of Trust issues related to Http permissions and Socket/SMTP permissions. The West Wind Web Store’s main operation runs without any issues in medium trust however there are two consistent issues that require some elevated rights:

Http Access for Credit Card Validation

If using a credit card provider that uses HTTP access such as Authorize.NET, AccessPoint, BluePay etc. HTTP access is required. Medium doesn’t allow Web Permissions although you can override the basic setting via the <trust orignUrl> in Web.config like this:

 

<trust level="Medium" originUrl="https://www.authorize.net/.*"  />

 

Or even more generically:

 

<trust level="Medium" originUrl=".*"  />

 

(kinda defeats the whole issue of no Web Permission doesn’t it? <s>)

 

Note that the value you specify is a RegEx expression not a wildcard value – that had tripped me up a few months back (just noticed that the same happened to Haacked. When you look at samples you often see the * and assume wildcard <g>.

 

IAC, this works fine in the default Medium trust environment, but it can and usually is overridden for major ISPs for reasons described in detail here.

 

Smtp or Socket for SMTP Confirmations

The West Wind Web Store sends out confirmation emails after orders are completed as well as using email for password retrieval and also for admin notifications of errors to the Administrator.

 

Currently the store uses a custom SMTP implementation mainly because the 1.1 version of System.Web.Mail didn’t support async operation and couldn’t connect send a few emails and disconnect. I haven’t gotten around to porting/extending the class to use the new System.Net.Mail client.

 

So currently I’m stuck with Socket connections that are outbound to a mail server. Again this is not supported by Medium trust. For kicks I did wrap the System.Net.Mail class as well and tried that but it too fails with System.Net.Mail.SmtpPermission errors.

 

 

I don’t extensively deal with big hosting companies. My server sits with a small ISP that I personally know and they trust me enough to never have worried about locking me down thankfully. Most of the customers I work with use internal servers that they control so they typically run in environments where trust is not a huge issue either.

 

 

So… what is the common scenario for Webhosts and how hard is it  convince them to open up these permissions in a way to make SMTP and Web Permissions to at least one site work? Any experience?  

 

Posted in ASP.NET  

The Voices of Reason


 

Kev
March 06, 2007

# re: Medium Trust - WebPermissions and SmtpPermissions

It depends on the hoster and how nicely you ask them <g>. I work for a small to medium sized UK shared/dedicated hosting company and over time we've had to tweak the partial trust policy on a case by case basis.

For example, we permit unrestricted access in the WebPermission class because customers require access to ever changing external datasources and web services and it's just not practical to even try and control this. At then end of the day, the servers still run ASP and they have unfettered access to ServerXMLHttp to do plenty of damage with anyway.

That said, our network infrastructure allows us to control the passage of traffic within the hosting VLAN's and hopefully detect/prevent any misbehaviour. All our critical internal systems are also heavily locked down and secured, of course.

Kev

Liming
March 15, 2007

# re: Medium Trust - WebPermissions and SmtpPermissions

My hosting company is strict, so I can't use any of the above options. My product is geared towards people in a shared host environment as well, so I have to make sure nobody is left out.

I'm suprised that you are bold enough to go with this solution though. Did you happen to know that most of your customers would have control of their own servers?

Rick Strahl
March 15, 2007

# re: Medium Trust - WebPermissions and SmtpPermissions

If you want to have certain features you'll have to have a certain set of rights. There's really no other solution. You can't work around that - either you enable these features (or switch to a host who is more lenient) or you have to live without the features. The HTTP/SMTP issues in particular have no workarounds so it's a complete either or scenario.

Aymeric
May 10, 2007

# re: Medium Trust - WebPermissions and SmtpPermissions

Hi everybody,

If I well understand (sorry for my english !!!), sending email from a .net 2 application hosted by a strict Medium trust level is not possible ?

But I have read this ...
http://msdn2.microsoft.com/en-us/library/aa480472.aspx
...
In version 2.0, SmtpPermission is available at Full, High, and Medium trust levels. This allows applications to send e-mail.
...

or this

http://msdn2.microsoft.com/en-us/library/ms364078(vs.80).aspx

Similarly to the SqlClient namespace, the ability to send e-mails is another ability that a number of applications would need. With the .NET Framework 2.0 comes a new permission, SmtpPermission, which is included in the default partial trust grants for ASP.NET 2.0 Web applications. This permission in turn is demanded by the SmtpClient class.
...

So possible or unpossible ? If yes, has anyone an exemple of SmtpPermission implementation with SmtpClient ?

Help would be appreciate ... thanks in advance

Rick Strahl
May 10, 2007

# re: Medium Trust - WebPermissions and SmtpPermissions

When I try to send email with Medium trust it fails, using native SMTP or a custom component I use (which uses SocketPermissions). If I remember right the stock .NET mail component also fails with socket permissions not SMTP permissions.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024