A Blog for Graymad

No, it's not the rant you've seen already regarding what a pain it is that Microsoft enables this feature by default.

No, my rant is that I've seen too many developers, some of whom I respect and know to be very smart people blithely recommend turning this feature off at the machine or application level. For example:

Today I installed V1.1 of the framework.  It was great, I installed the PocketPC version of TaskVision, deployed it to the emulator and "poooof" - there it was, like magic, my first deployment of a PocketPC application {takes a majestic bow}.

After that magnificent victory I strode back to Mt. Doom to do battle with the Dark Forces of Sauron (a.k.a. CMS 2002) :-)  Guess what happened next?

> Server Error in '/Blah' Application.
> -----------------------------------------------------------
> A potentially dangerous Request.Form value was detected from the client 

Would you look at that... my app just broke.  Just when I finally thought that I'd worked out CMS2002, the rug got pulled out from under me ;-)

I haven't bothered to check as yet, but, I imagine that the validateRequest Page attribute must have existed in V1.0 and that its value was set to false by default in the machine configuration file and that V1.1 decided that we needed to have it.  I guess that I should go on record as saying that, "I don't believe that we needed to have it.".

To disable it, you can turn it off in the config file like so:

<system.web>
    <pages validateRequest="false" />
system.web>

[Darren Neimke]

Now I can understand the frustration with breaking changes, but like Paul Wilson, I applaud the ASP.NET team for including this feature in v1.1 and for turning it on by default. And I'm a little miffed that after all of the complaints Microsoft has had to endure about non-secure defaults, the reaction to a default setting that can (if not blithely disabled) eliminate scores of web application vulnerabilities has been less than encouraging, at best.

I'll grant that folks like Darren are probably experienced enough to take care of filtering or encoding input on their own. But I'd hope that they would also recognize that folks who read their blogs may not be. And telling folks "here's how you disable this PITA feature" without warning them that by disabling Request Validation, they will be vulnerable to cross-site scripting attacks unless they specifically ensure that they filter or encode user input before displaying it, is not a good idea, IMO. So please...a request to my fellow developers. If you're going to diss Request Validation, at least provide a caveat before telling people how to disable it.

I realize the correct solution is to fix w.bloggar, but could you just uninstall/reinstall and put it into a folder where writing was allowed (your My Documents folder, or :\w.bloggar if multiple users required access...)?

Sure, both of those solutions would probably work...but only if you know enough to know why the software's failing in the first place. If you don't know that going in, how are you going to know to install to a different directory? And like the suggestions made by Drew, these are workarounds, not true solutions. As such, they really don't address the larger issue of getting developers to test their software and make it run without elevated privileges, and without having to resort to workarounds or hacks.

Bottom line is that software should not, as a general rule, require admin privileges, or loosening of permissions on install directories, to run properly. If software requires elevated privileges, it should ideally provide a means for the user to temporarily provide those elevated privileges for the smallest amount of time and scope necessary, and then the application should be returned to the lowest possible privilege level. So I thank Duncan for the additional workaround ideas, but I don't want more workarounds. I want software that operates properly without them.

My new books, Microsoft® ASP.NET Programming with Microsoft Visual Basic® .NET Version 2003 Step By Step and Microsoft® ASP.NET Programming with Microsoft Visual C#® .NET Version 2003 Step By Step, have been released.

These books provide a step by step approach to learning ASP.NET with Visual Studio .NET, and have been updated for Visual Studio .NET 2003, and version 1.1 of the .NET Framework.

I welcome feedback on the books at feedback@aspnetsbs.com.

Seems to work pretty well, with one caveat. Since I'm running w.bloggar using Run As... and an admin account, I have to run WMP with the same credentials in order to get the plug-in to work.

It's never easy trying to avoid privilege elevation. :-)

You can grant read/write access to all users (or just your non-admin account) to the w.bloggar installation directory. The directory is usually c:\Program Files\bloggar. This will allow the non-admin user to create accounts.
http://erablog.net/filters/10933.post

Now, Drew is correct about the fix. But this only highlights my point. Applications aren't supposed to write user data to the Program Files tree in the first place. That's what the user's folder under the Documents and Settings folder is for. If w.bloggar wrote to the user's MyDocuments folder instead (or to the Application Data or Local Settings folders under the user's root folder), there would be no need for loosening the permissions on the w.bloggar install directory or running as admin to get it to work right.

I don't mean to beat up on w.bloggar. I like it, and I appreciate the fact that the developer took the time to write it and make it available. But it's also a good example of how a very simple change in a program makes the difference between a program that requires elevated privileges, and one that doesn't. I've emailed Marcelo about this, and I hope that in a future release he makes the change. We'll see.

Writing this post from w.bloggar. Nice UI, and good features (I especially like being able to easily post links to a new window, which has been a pain until now), but it breaks one of my primary pet peeves these days...it must be run using an administrator account in order for it to function properly.

If you're not logged in as an administrator (or running w.bloggar using the Run As... feature with an Admin account) w.bloggar will not be able to create a new account. I haven't seen anything yet that it does that should require administrator rights, so this shouldn't be the case, IMO. As I've posted on numerous occasions, this is bad because it tends to encourage people to simply run their computers using an administrative account on a day-to-day basis, and as a result, they are subject to a wider array of security vulnerabilities. Additionally, where developers are concerned, the problem is circular, since developers who run as admin often neglect to test their code from a non-admin account, which is why we end up in this situation in the first place.

So kudos to Marcelo L. L. Cabral for creating w.bloggar and releasing it as freeware. But I hope that he'll take some time to test it using a non-admin account, and make changes so that you don't need to be an administrator to use it.