Miesiąc: czerwiec 2010

Request validation in ASP.Net 4.0

Hello again,

recently, while migrating one of our web applications to .NET Framework 4.0, we came across a following issue. The app’s main goal is to store some HTML articles in the database. However, when a user made a postback when saving an article, he got the following error message:

A potentially dangerous Request.Form value was detected from the client (ctl1…)

This kind of message is known to ASP.net 3.5 and 2.0 developers. The standard workaround for this issue was either to configure a single page not to validate request: 

Page validateRequest=”false”

..or, globally for the whole application, via web.config:

<pages validateRequest="false" />

We had the second option chosen, since only a couple of trusted and authenticated users were using the app. But, as already said, the error came up after migration to 4.0 Framework. The request validation was disabled in the <pages> node, but for ASP.Net 4.0 it seems not to be enough.

There are some security improvements in the latest version of ASP.Net, protecting from cross-site-scripting (XSS) attacks. New default protection not only applies to aspx pages, but to all kind of requests, like web service calls and custom handlers, even when using our custom HTTP module(s).

That was the reason why our app threw errors which it didn’t do before. In order to restore previous behavior of ASP.Net applications one has to set the request validation mode backwards, for the 2.0 version. In web.config, you just add following attribute to the <httpRuntime> node:

<httpRuntime requestValidationMode="2.0" />

Hope this helps.

Lukasz

IE’s attachment handling on Tomcat via https

Howdy,

today something from a bit different discipline. Recently some users of one of java applications running in the company reported quite odd behavior. While they were trying to download any attachment / binary file generated by the application, they got the following error message as popup in Internet Explorer (versions 7 and 8):

„IE cannot download…………IE not able to open site..requested site is unavailable or cannot be found…”

After the message, the download was suspended and they couldn’t get the attachments. In all other browsers (FF, Opera, Chrome and Safari tested) the problem was not occuring. The application is running over https on Apache Tomcat 6.

First suspect was of course a bug in the application. After some research it turned out not to be the case. It seems to be a bug in Internet Explorer itself. Non-cache headers seem to prevent the browser from downloading attachments when working over a secure channel. Microsoft released a hotfix for it, but apparently only for the IE 6.

In order to workaround the issue, one can force Tomcat not to send the non-cache headers on response. The way to do that is to put the following valve in the Context.xml configuration file of the server (between <context> tags):

<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator"
disableProxyCaching="false" />

After that (server restart required), it seems to work fine, with no side effects.

Hope this helps,
Lukasz

Custom tags and attributes in a SyndicationItem

Hello again,

for those of you who are not quite satisfied with the standard syndication functionality of .Net, here is a small tip on how to extend the XML generated from the SyndicationFeed class in C#.

Let’s assume we would like to have a RSS feed, which in fact would serve as a podcast, e.g. for iTunes. The software from Apple uses some information from their custom-defined RSS-tags, with an “itunes” prefix, for example:

<itunes:author>Anonymous One</itunes:author>

Without this prefix it’s very easy. Our SyndicationItem class provides us a functionality to extend the standard item’s elements:

SyndicationItem item = new SyndicationItem();
item.ElementExtensions.Add("customTag", String.Empty, "My test");

The second attribute is the namespace which comes into play in the next step. In order to add the tag prefix as mentioned before, one has start with adding the namespace to the feed instance:

SyndicationFeed feed = new SyndicationFeed();
XmlQualifiedName n=new XmlQualifiedName("itunes","http://www.w3.org/2000/xmlns/");
String itunesNs = "http://www.itunes.com/dtds/podcast-1.0.dtd";
feed.AttributeExtensions.Add(n, itunesNs);

Now that we have added the new namespace to the feed, we can start adding custom item elements within that namespace.

SyndicationItem item = new SyndicationItem();
item.ElementExtensions.Add(new SyndicationElementExtension("author",
     itunesNs, "Famous author"));

That should solve the issue with custom tags with custom prefixes. One more thing.. it may be quite useful for those which attach media files to their podcasts: the enclosure tag.
In order to add such an element to the SyndicationItem, we can use the SyndicationLink object as follows:

SyndicationLink enclosure =
           SyndicationLink.CreateMediaEnclosureLink(
               new Uri("http://example.com/01.mp3"), "audio/mpeg", 1200);
item.Links.Add(enclosure);

The method takes three arguments: the URL , type (MIME-type) and length of media attachment.

Hope this helps.

“Please wait while scripts are loaded…”

Hello again,

Some of Sharepoint developers might be familiar with this kind of message. It appears in the status bar of Internet Explorer when some action is executed. If the message disappears, fine, but what if it remains there and the desired behavior isn’t executed?

There are a couple of blog entries over the net that describe possible reasons for this issue. What actually causes this behavior are either errors in a masterpage (wrong or missing ID’s of elements that are later referenced), or defective javascript. Well, to be clearer, defective javascript from Internet Explorer’s point of view. And it may take w while to debug and find out at which point the javascript is failing.

I was getting this “Please wait while scripts are loaded” message on a web part page with one particular web part, which had some custom verbs defined. Web part verbs are kind of menu items for a web part, that allow to perform some actions on it. For each verb, one can define server-side and client side action to be performed when the verb / menu item is clicked. And this client side code of the verb was the crux of the matter.

The idea was simple: to open a window via javascript. For the window.open() method two arguments were used, the URL and the name of the new window. The client side code was generated dynamically and the window’s name was put up together, amongst others, from personalizable properties of the web part. Everything worked fine until the property used as part of window’s name contained a hyphen (-). Then, after clicking on web part menu, the message described above appeared, and nothing happened, new window hasn’t been opened.

I replaced the string with an underscore and the problem was solved. At this time I thought that maybe the names or ID’s in aren’t allowed to contain characters like hyphen. But no, according to W3C, hyphens are allowed since they’re not the first character of ID or name. Probably Internet Explorer tries to evaluate the expression, treating the hyphen as a minus sign. And reaches a deadlock at some point (please wait while scripts are loaded…)

Hope this helps,
Lukasz