Troubleshooting

Yes We Can Music Video

Dave's Tech Shop — Fri, 08 Feb 2008 13:02:13 GMT

The will.i.am music video "Yes We Can" hit the Net on Friday and by Tuesday it had been streamed a staggering 10 million times on YouTube and the website www.yeswecansong.com.

Watch it.

Forms Authentication Cookies and Subdomain Names

Dave's Tech Shop — Thu, 21 Sep 2006 22:40:51 GMT

Does your ASP.NET web site have subdomains and use forms authentication with persistent cookies? Do you host your site or blog on a shared hosting platform? If so, you can run into a problem authenticating users because of the way cookie domains work. Here are the details of the problem and steps you can take to solve or prevent the problem.

Security or Login Problems Can Occur

For this example, let's assume you have a blog running blogging software (such as Subtext) that supports multiple blogs. Let's also assume you host at WebHost4Life because that is the assumption most articles on this blog have made so far. (However, this example also applies to all web sites with subdomains and forms authentication with cookies and shared hosting.) Say you have the following subdomains set up:

http://example.com (same as http://www.example.com - this is an aggregated blog or a home page)
http://racing.example.com (this is your friend's blog about racing)
http://csharp.example.com (this is your blog about C# software development)
and there could be any number of other subdomains

Assume you have user accounts at the aggregated blog (http://example.com) and the other blogs (e.g., http://csharp.example.com). When you log in to any of the blogs at this domain, ASP.NET writes an authentication cookie containing an authentication ticket for your login.

The Problem

Once you log in to http://example.com, you may find that you cannot log in to any of the subdomains. This happens because the authentication cookies for specific subdomains have a limited cookie scope. However, the authentication cookie for http://example.com is available to the primary domain and all subdomains.

Why the Problem Occurs

Let's say you have logged in to http://example.com earlier. Now you are logging in to http://csharp.example.com. When you log in, ASP.NET creates a FormsAuthenticationTicket with your username and some other information (such as IssueDate, Expiration, Version, etc.). This FormsAuthenticationTicket is stored in a cookie (for the type of configuration we are discussing). WebHost4Life (and probably other shared hosting providers) sets the cookie domain to be the actual domain specified in the URL. This cookie then belongs to that specific subdomain (the one you are logging in to). There are various security mechanisms that enforce this rule.

In this example, the cookie will be named youruser@csharp.example[1].txt. (The number may not be 1. It is usually 1 or 2.) The cookie will be located at "C:\Documents and Settings\YourUser\Cookies". Your previous cookie (from logging in to the primary domain http://example.com) will be named similar to youruser@example[1].txt and it will be in the same location.

After you log in, you are transferred to another page (usually some resource that requires you to have logged in). The request for this page causes ASP.NET to execute code for AuthenticateRequest (or OnAuthenticateRequest in your custom code such as an HttpModule, for example). One thing that happens in that code is that the authentication cookie you created when you logged in is retrieved. The code to retrieve a cookie looks similar to this:

HttpContext.Current.Request.Cookies[cookieName];

where 'cookieName' is defined in web.config like this:

ASP.NET (or your custom module) will obtain the cookie value and decrypt the authentication ticket. It will then create an instance of an IPrincipal and assign that IPrincipal to HttpContext.Current.User. The IPrincipal will follow your entire request. That's how it should work anyway.

However, in the situation, the cookie retrieved is the cookie from your previous login to the primary domain. This is the wrong cookie! At least it is wrong for our needs. (However, this behavior is by design. It is not a bug. Any cookie without a subdomain name is available to all subdomains and the primary domain.) This incorrect cookie contains an authentication ticket for the user account at the primary domain. Depending on how your code is written, the IPrincipal user account may not have the correct roles now. It probably doesn't have the correct user name. Obtaining the incorrect authentication ticket can have various serious problems, as you can imagine.

The Solution

ASP.NET retrieves cookies (within a domain) by name (e.g., ".MyCookieName" as configured above). Configurations like I am describing use the same cookie name for the primary domain and all subdomains. Changing that is one route to a solution -- assuming you do not have control over the cookie domain property, as is currently the case at WebHost4Life.

If the cookie for http://csharp.example.com had a name similar to .MyCookieName.CSharp, then the normal ASP.NET code that retrieves the authentication cookie would work correctly. However, each subdomain needs a uniquely named cookie and there is no way to achieve this using the settings in web.config.

Therefore, you have to implement code to give each authentication cookie a unique name. Here is the approach I took recently. This is from code for the Subtext personal blog publishing platform. I decided to rely on the cookie name configured for forms authentication as the root name and attach various suffixes to this name to distinguish cookies for each subdomain.

The 3 basic steps I took are:

Create the unique cookie name;
Add the cookie to the response with the correct cookie name;
Select the correct cookie by name in AuthenticateRequest.

First, I created a method that would create the suffix and then make a unique cookie name. In the case of Subtext, each subdomain is associated with a specific blog. Therefore, I named the cookies using blog identifiers. In the code below, I get the cookie name configured in web.config, and then I get the blog ID and make a unique cookie name.

private static string GetFullCookieName()
{
    string cookieName = FormsAuthentication.FormsCookieName;
    StringBuilder name = new StringBuilder(cookieName);
    name.Append(".");
    name.Append(Config.CurrentBlog == null ? "null" : Config.CurrentBlog.Id.ToString());
    return name.ToString();
}

When setting the authentication ticket, I simply call the method above to get the correct (unique) cookie name. I included the entire method because the code shows something else of interest. As others have discovered, there is no good way to directly obtain the timeout value configured in web.config for cookie timeouts. The way I did it is by having ASP.NET make a temporary authentication cookie for me and then copying the timeout data (and other information too) from that temporary cookie. Once that is done, I simply set the correct cookie name and add the cookie to the response.

NOTE: In ASP.NET 2.0, you may think you can use the strongly typed configuration classes to access values such as the authentication cookie timeout. However, that will not work in partial trust. You are making sure your web app will run in partial trust, right? If you don't want to take my approach for accessing the cookie timeout value, you could duplicate the web.config setting for forms authentication timeout in the appSettings section of your web.config file. Having the same value configured in two places is not ideal, however. That's why I chose the method shown below.

public static void SetAuthenticationTicket(string username, bool persist, params string userData)
{
    //Getting a cookie this way and using a temp auth ticket
    //allows us to access the timeout value from web.config in partial trust.
    HttpCookie authCookie = FormsAuthentication.GetAuthCookie(username, persist);
    FormsAuthenticationTicket tempTicket = FormsAuthentication.Decrypt(authCookie.Value);
    FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(
        tempTicket.Version, tempTicket.Name, tempTicket.IssueDate,
        tempTicket.Expiration,//this is how we access the configured timeout value
        persist, userData, tempTicket.CookiePath);
    authCookie.Value = FormsAuthentication.Encrypt(authTicket);
    authCookie.Name = GetFullCookieName();//use our custom cookie name
    HttpContext.Current.Response.Cookies.Add(authCookie);
}

ASP.NET can exhibit some bizarre behavior when it comes to cookies. Cookies can disappear during debugging and cookies can even be created out of thin air. In fact, the innocent act of getting a cookie from the Response cookie collection can create a cookie in the Request cookie collection! Here is an excellent article by Paul Riley that covers all the details of those gotchas. Now, back to the specific solution.

In your code that handles AuthenticateRequest, you need a way to select the correct authentication cookie by name. I used a method called SelectAuthenticationCookie. The code below shows the call site.

void OnAuthenticateRequest(object sender, EventArgs e)
{
HttpCookie authCookie = Subtext.Framework.Security.SelectAuthenticationCookie();
//the rest of your authetication code would follow this.
}

The method is implemented as shown below. Note that it uses the same GetFullCookieName method created above. In the code below, I use a for-loop, but I assume you may want to use some other type of loop (foreach?). I am trusting the jitter to handle the multiple calls to GetFullCookieName efficiently.

public static HttpCookie SelectAuthenticationCookie()
{
    HttpCookie authCookie = null;
    for (int i = 0; i < HttpContext.Current.Request.Cookies.Count; ++i)
    {
        HttpCookie c = HttpContext.Current.Request.Cookies[i];
        if (c.Name == GetFullCookieName())
        {
            authCookie = c;
           break;
        }
    }
    return authCookie;
}

As you can see, the code sets and gets the cookie by using the same GetFullCookieName method. That's all it takes to solve this problem.

If you want to look at a running example of the code, go to the Subtext project and use Subversion to get rev 1762 or later of release 1.9, which is currently located at https://svn.sourceforge.net/svnroot/subtext/branches/Release1.9/. (FYI, I assume this code will change completely in Subtext 2.0 when it is released. It could change before that.)

Cannot log in to blog in Subtext 1.9 with multiple blogs

Dave's Tech Shop — Sun, 17 Sep 2006 16:34:28 GMT

A reader just emailed me and asked about a problem logging to to his blogs. It turns out that I have been wrestling with this issue for a week or more and I have heard from a couple other people having the same problem in the last few days.

Here is a description of the problem:

If you have multiple blogs configured in Subtext 1.9, you may experience a situation where you cannot log in as the admin to one or more of your blogs.

The problem appears to only happen when those multiple blogs are configured using subdomain names. For example:

mydomain.com
blog1.mydomain.com
blog2.mydomain.com
blog3.mydomain.com

The problem is related to the fact that one of the blogs is accessible at the primary domain without any subdomain:

http://mydomain.com

Some shared hosting providers are apparently specifying the ASP.NET cookie domain property outside of the application's code (where the application is Subtext in this case). That means that when you access your blog using http://mydomain.com and the cookie domain property has been set, that cookie will essentially "hide" all your other authentication cookies as far as Subtext is concerned.

[UPDATE Sept 2006] The latest Subtext code should solve this problem. Here is an article explaining the approach I took. I have only tested the solution at WebHost4Life so far. If you build Subtext from the source code, you can try this solution out yourself. If you do that, please give us some feedback. If the testing goes well, this solution should be part of the next Subtext release (which will be v1.9.1 I believe).

To solve the problem, follow these steps:

On the computer you are using to access your blog, go to:

C:\Documents and Settings\YourUserName\Cookies

Search for any cookies that have your blog's domain name in them. I search on file names that include the term "mydomain" where my blogs are named as shown above.

Delete all the cookies.

Close any open browser windows.

Now try to log in to your blog as admin. You should have success. If not, you may need to repeat the steps and verify the all the Subtext cookies are deleted. They all have the name ".SubtextCookie" inside them. Searching inside the content of the cookies is another way to perform the search I mentioned above.

I have now tested this solution several times. Once I delete the cookies and close my browser, I am once again able to log in.

The problem happens as soon as Subtext writes a cookie to my system with this file name:

MyUserName@mydomain[n].txt where n is usually 1.

There may be other cookies that exist with names such as:

MyUserName@blog3.mydomain[n].txt
MyUserName@blog2.mydomain[n].txt
MyUserName@blog1.mydomain[n].txt

As soon as the cookie without the subdomain name gets written, the login problem occurs. In fact, the cookie without the subdomain name is the only one that needs to be deleted.

Logging in as HostAdmin using a URL without a subdomain can also create this cookie without a subdomain name, and once that happens, the same Admin login problem will occur.

Any time you cannot log in, you will need to repeat these steps to delete the Subtext cookie!

I am fairly sure this issue will be fixed in Subtext very soon. For now, the above work-around should help.

Troubleshooting - Using log4net

Dave's Tech Shop — Fri, 15 Sep 2006 18:51:59 GMT

When your blog is having technical issues it often helps to look at a log of errors. This is especially true when using a remote shared host that you have limited access to.

This article describes how to get Subtext's built-in logging enabled at WebHost4Life. Subtext uses log4net as the logging provider. Among the many logging options, log4net can send error messages to you by email and it can log errors to the Subtext database. However, the easiest solution when nothing seems to be working is to log to a file. (Otherwise you may find yourself troubleshooting email or database connections in addition to whatever you were initially trying to fix. When logging to a file, you don't have to have a working db connection or mail server configured yet.)

Unfortunately, I recently had a situation where I could not even get logging to a file to work. That motivated me to create this article.

Here are the steps to get log4net to log to a file on your shared hosting account at WH4L.

Log in to your WH4L Control Panel.
Create a folder under your Subtext installation folder (usually Subtext.Web) called Logs.
Follow the instructions here to change file permissions on the Logs folder so that the Network Service user account has write permissions to the Logs folder.
Find and edit the file Log4Net.config. It is in your Subtext installation folder (usually Subtext.Web).
Add the following block of code right under the <log4net> element opening tag:

<appender name="FileAppender" type="log4net.Appender.FileAppender">
    <param name="File" value="c:\\hosting\\webhost4life\\member\\your_account\\Subtext.Web\\Logs\\your_blog.log"/>
    <param name="AppendToFile" value="true"/>
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%-5p %m [%r] %d{ABSOLUTE}%n"/>
    </layout>
</appender>
Be sure to change the "File" value to your exact path.
Note the double backslashes and the full physical file path. I was not able to get relative file paths to work at WH4L.
Near the bottom of the Log4Net.config file, in the <root> element, add the following line:
<appender-ref ref="FileAppender" />
Also in the root element, change the level line so it reads like this:
<level value="DEBUG" />
After you edit Log4Net.config and upload the edited file to your web server (overwriting your original file), you can restart your blog. I usually restart it by editing web.config. I just make a change in a comment and save web.config and the blog will restart.
When Subtext restarts, it will write the following message in the log file (which you have named similarly to \Logs\your_blog.log): Application_Start - This is not a malfunction.
Once you see the \Logs\your_blog.log file has been created and Subtext is logging to it, you can begin solving whatever other technical issues you might be facing. As I said, having access to an error log is often the very first troubleshooting step.
If you cannot find the log file on the file system, or if you find it but it is zero bytes, then something in your configuration is still not correct. Keep reviewing the steps until you get Subtext and log4net to write a log file. When everything is working, the log file should at least contain the Application_Start message cited above.
For more information on log4net, see the project site. You can find configuration examples and full documentation there. And if you really need detailed info on log4net, the mailing list archives are a great resource!
Another thing you might want to do is set up the logging to send you emails when errors occur. The steps are the same as above, but instead of working with the FileAppender in log4net, you work with the SmtpAppender. When the SmtpAppender is properly configued, Subtext will send you an email whenever any errors occur. Below are my SmtpAppender settings from Log4Net.config:

snip...