I just shifted a number of sites to this hosting company. As you'll likely be aware it's pushing a sort of virtual host concept which claims to be more flexible than older approaches. It seems to be flexible; it remains to be seen how reliable it all is.

There are a few things which are different here compared with standard IIS7, probably because of their internal architecture.

1 Impersonation, File Permissions

The IIS7 web server in Mosso's setup doesn't have the rights to write to its own file space, so you need to increase your priviledge level in order to do that. Microsoft explain how to sort it out .. the crude way is just to stick something like this in your web.config:

<system.web>
 <identity impersonate="true" userName="dfw\name" password="pj87^lopw" />
<system.web>

The code to do this programatically is available from the suppliers here. That's a little more secure.

I use web.config impersonation for BlogEngine itself as that's self contained; where I'm doing other things I use the programatic approach as that's a fraction more secure.

One thing to watch out for is the way Mosso's ftp users interact with this. If you impersonate, for example, the prime account user, you may well not be able to write into directories created by a subsidiary (more restricted) ftp user. Typically I use ftp accounts like those for photographers to upload their images to sites without giving them full access to the rest of the site's files. The catch then is that I need to know who owns a specific directory before I can impersonate that person...

2  SMTP - Sending email from a Mosso Site

Mosso use authenticated SMTP; just pick an account to use and put the credentials in web.config and it all hums along:

    <system.net>
        <mailSettings> <!-- Outgoing mail settings -->
            <smtp>
                <network host="smtp.someserver.com" userName="sendfrom@adomain.com" password="Ox^7hu0v4:B" />
            </smtp>
        </mailSettings>
    </system.net>

 

3  SSL - Secure Pages

This is interesting. If you sit on an IIS7 machine (or "cluster" or whatever it is) inside Mosso and watch the incoming requests, they're all http, port 80. So you don't, for example, see https requests in the same way you do on a standard IIS7 install. That is, 

Request.IsSecureConnection

always returns false, even for https:// requests.

If you have a system for auto-magically forcing pages to be either https or http, then this can cause a problem as the protocol check doesn't return the correct value for https pages. The solution's simple, but it's not in the Mosso KB and their (generally very good, so far) technical support guys aren't on it. These guys led me to the solution, which is that whatever front-end system you hit in Mosso which translates that https back to http for you kindly injects an additonal value into the server variables, so:

bool https = (Request.ServerVariables["HTTP_CLUSTER_HTTPS"] == "on")? true : false;

Will return true or false as you'd expect depending on the incoming protocol.

I use a common class which does the switching as required for each page. The logic is something like this fragment:

 

  Uri currentUrl = System.Web.HttpContext.Current.Request.Url;
  bool https = (Request.ServerVariables["HTTP_CLUSTER_HTTPS"] == "on")? true : false;
  UriBuilder newUrlBuilder = new UriBuilder(currentUrl);
  newUrlBuilder.Port = -1; 

  if (RequireSSL)
  {
    if (!https)
    {
       // Page needs https but is not yet on it.
       newUrlBuilder.Scheme = Uri.UriSchemeHttps;
       Response.Redirect(newUrlBuilder.Uri.ToString());
    }
  }
  else
  {
     if(https)
     {
        // Page does not need https but is on it.
        newUrlBuilder.Scheme = Uri.UriSchemeHttp;
        Response.Redirect(newUrlBuilder.Uri.ToString());
     }
   }

And it all works as expected with the ServerVariables as above.

 

4  Web.config, Changes and Encryption

There's something odd about Mosso's architecture. I'm not sure what precisely it is: presumably something to do with the "clustering" or "cloud" business. It's slightly tricky to get the server to recognize file changes; sometimes you have to actually delete web.config and then re-upload it in order to force changes to aspx pages to take effect.

One thing you can't do it seems (and Mosso's generally very good support agree) is to encrypt sections of your web.config. Even if you're running at the right priviledge level, you can't programatically write to web.config, which is what you generally do to encrypt sections of it. There are good reasons for wanting to do this: for example, if you encrypt your database connexion strings in your web.config you can prevent simple compromise of the web server leading to compromise of the database server. Sadly you can't just put the sensitive bits of the web.config in a subsidiary config file and work that way; encrypting just the subsidiary file still requires the sort of access to web.configwhich Mosso can't give you. An alternative approach would be to use public key cryptography on the bits of file you're interested in, but in asp.net that requires access to aspnet_regiis.exe on both development and deployment machines... and you can't access that on the Mosso cluster.

 

5 Client IP Adresses

Yes yes, you can't rely on them, but they are used by BlogEngine and much of my own stuff to track the source of requests. That's what:

System.Web.HttpContext.Current.Request.UserHostAddress

is for, or the server variable REMOTE_ADDR. Anyway, for Mosso you get the IP address of some of their internal systems - the load balancer probably. Fortunately they add a few extra server variables, of which one will do the job for REMOTE_ADDR:

HTTP_X_CLUSTER_CLIENT_IP
HTTP_X_FORWARDED_HOST   
HTTP_X_FORWARDED_FOR
HTTP_X_MOSSO_DT
HTTP_X_FORWARDED_SERVER

The one in green returns the value you'd expect to be in REMOTE_ADDR.