Category Archives: ASP.NET

Easily Work With Differing Time Zones In An ASP.NET 3.5 Application

When working with ASP.NET applications, time zones are often a problem when dealing with
DateTime structures. There are two different common scenarios that a developer is likely
to encounter. The first is that you are placing the application on a hosted server
that is in a different time zone than the business you are trying to operate. The second
is that you have users from different time zones and would like to display the date and time
to the user in their local time zone rather than the server’s time zone.

Hosted Time Zone addresses this problem by providing two settings. ApplicationTimeZone sets
the time zone to be used by the entire application. ThreadTimeZone sets the time zone to be
used by the currently running thread, which defaults to the ApplicationTimeZone if no time
zone has been specified on the thread. If you are using ThreadTimeZone then you need to be
sure to set the value for each request made to the server. You will usually do this in your
global.asax file, such as in the Application_BeginRequest handler.

To actually perform the conversions you can call the ToAppTime, FromAppTime, ToThreadTime, or
FromThreadTime static methods on the ApplicationTimeZone class. Additionally, extension methods
have been declared for the DateTime and DateTimeOffset classes that perform the same functions
more cleanly. In order for the extension methods to work you must import the HostedTimeZone
namespace.

You should note that there are not any overloads for FromAppTime or FromThreadTime for the
DateTimeOffset class. This is because the ToLocalTime method of DateTimeOffset performs the
same function, so they would be redundant.

This library requires the TimeZoneInfo class, which is not available until the .NET Framework 3.5.
Therefore, it is not compatible with ASP.NET 2.0 or earlier.

Hosted Time Zone 1.0.0.0

Using URL Rewriting With Web Parts

Web parts are a great new system for allowing personalization of web sites by end users that
was introduced in ASP.NET 2.0. However, it isn’t useful when used in combination with
URL rewriting.

URL rewriting allows you to respond to requests from dynamic URLs by redirecting the handling
to a different .ASPX file on your server. This can be used to make your URLs more readable
and improve your search engine optimization (SEO), instead of using long query parameters.
Some example systems for implementing this are UrlRewriter.net and UrlRewriting.net.

When you use web parts in combination with a rewritten URL, the web parts will all be shared by
all of the URLs that are rewritten to the same .ASPX file. This library corrects this
by replacing the WebPartManager with RewritableWebPartManager and the SqlPersonalizationProvider
with RewritableSqlPersonalizationProvider.

It also provides additional functionality in the form a personalization levels. This allows you
to share common personalization settings amonst multiple URLs. When a user is browsing, if no
personalization is specified at a particular level, the personalization defined at a higher level
is displayed instead. For example, in a web store scenario you can allow the store operators to
provide shared personalization that all users will see. Using levels, they can set personalization
that will appear on all item pages, such as a disclaimer, and then override that personalization
with a different disclaimer on a specific item’s page.

More information can be found in the readme file included in the download.

Rewritable Web Parts Library 1.0.0.0

Update To Partial Authentication System

I’ve posted an improvement to the Partial Authentication System originally posted at Secure Persistent ASP.NET Forms Authentication.

I discovered a problem in the automatic redirection of requests back to HTTP from HTTPS using the requiresSSL=”None” setting in the authorization section. Since most sites would set this to none for their root folder, this caused a problem with the links generated by ASP.NET and AJAX to WebResource.axd and ScriptResource.axd, which are logically (not physically) located in the root of the web application. If you have a secure page in another folder which requests these resources, they were being redirected back to an insecure connection, causing a potential security flaw and causing Firefox to display warnings about partial security.

This has been addressed by ignoring the requiresSSL=”None” setting for a request for any file with the “.axd” extension, effectively treating it as requiresSSL=”Optional” instead. Note that requiresSSL=”Required” is still enforced as normal for files with this extension.

I’ve posted new source and binaries for download.

UPDATE: Please see updated version here