Problems setting up ASP.NET 4.0 web on IIS 7


I was attempting to set up a new ASP.NET 4.0 web on my dev machine, running Windows 7 and IIS 7. I ran into several errors, that I suspect others may encounter, and I had to search all over the web to find all the answers. So I’ve written this post in the hopes it saves some other dev the same headache I had!

So, first I created the new website and app pool identity, but when I hit the site for the first time, I got the following error:
HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

After searching for solutions, I found most had to do with permissions to the web.config file or actual locking of sections of the web.config file. I confirmed that the app pool identity had permissions to the file, and there were no locking attributes in the file. So something else had to be the issue. Then I found this post:
It turns out that ASP.NET had not been configured fully on my machine. So, according to one of the answers on the post, the solution is to do the following steps:
1. Open control panel
2. Click on “Programs and Features”
3. Click on ”Turn windows features on/off”
4. Locate ”Internet Information services IIS” in the pop up window and expand its node
5. Expand the ”World Wide Web Service” node
6. Expand “Application Development Features” node
7. Check the check box of”ASP.NET”
8. Then click ok button
9. You will need to restart your computer (go get a cup of coffee…)

After restarting, and hitting the site again, I got this new error:
HTTP Error 500.21 – Internal Server Error
Handler “PageHandlerFactory-Integrated” has a bad module “ManagedPipelineHandler” in its module list
Another web search revealed that even though the step above enabled ASP.NET, it was not fully installed. This article shows how to finish the installation:
Basically, just open a command window and enter the command shown below (command is slightly different for 32-bit vs. 64-bit).
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i

32 bit:
%windir%\Microsoft.NET\Framework\v4.0.21006\aspnet_regiis.exe -i

If you get a permissions error, you need to run the window as an administrator. To do this, go to start |run, and type ‘cmd’, but hit Ctrl-Shift-Enter, instead of just Enter.
After doing that, I hit the site again, and it worked! Hope this has helped!

I Love Python: ReSTful DB CRUD dispatching using CherryPy


CherryPy has been one of my favorite Python tools for several years. It should be mentioned here that a ReSTful dispatcher could easily be written in, or pylons as well, and even comes for free in the latest TurboGears implementation.

But if you’re looking for a small, easily manageable and extremely dynamic ReST dispatching solution without the heft of an entire web framework, I’m about to show you how CherryPy can help you in three different ways, depending on your model.

Assuming this mapping:

HTTP POST = DB update
HTTP PUT = DB insert

Let’s also standardize on one common method across all examples, for determining the HTTP request type, and matching it to the function of the same name. Here is the full code snippet for accomplishing this task:

methods = ('OPTIONS','GET','HEAD','POST',

if cherrypy.request.method not in self.methods:
    raise cherrypy.HTTPError(400,'Bad Request')

# If request method is HEAD, return the page handler
# for GET, and let CherryPy take care of dropping
# the response body
method = cherrypy.request.method

if cherrypy.request.method == "HEAD":
    method = "GET"

http_method = getattr(self,method)

#print "HTTP Method: %s" % method


In our examples, we’re going to shorten this to:

http_method = getattr(self.m,cherrypy.request.method)
return (http_method)(args,kwargs)

All of this essentially determines how HTTP was called (GET/PUT/POST/DELETE), and calls the method in a class which exactly matches this name (self.GET(), self.PUT(), etc)
When you see this code, know that it’s just the HTTP method resolving code.

Now for the fun. Let’s look at the dispatcher options we have.

Way 1: A hard-coded URL pointing to fixed resources:

CherryPy can be used in a manner similar to this to establish a fixed URL, and corresponding resources, driven from predefined classes instantiated in the ‘root’ hierarchy:

import cherrypy

class ReSTPaths1:
	def index(self):
		http_method = getattr(self,cherrypy.request.method)
		return (http_method)()

	def GET(self):
		return "In GET 1.."

class ReSTPaths2:
	def index(self):
		http_method = getattr(self,cherrypy.request.method)
		return (http_method)()

	def GET(self):
		return "In GET 2.."

class ReSTPaths3:
	def index(self,client_id=None):
		http_method = getattr(self,cherrypy.request.method)
		return (http_method)(client_id)

	def GET(self,client_id=None):
		return "IN Get 3, your client_id is %s\n" % (client_id)


root.client = ReSTPaths2()
root.client.address = ReSTPaths3()

Once this is running, the URL to invoke it looks like this:






Output looks something like this:

In GET 1..
In GET 2..
IN Get 3, your client_id is None

If you’re new to CherryPy or Python in general, I’ll reiterate for you how we are calling the GET method in our class.

When we issue this request, we’re issuing what HTTP calls a GET request:


The CherryPy service above, listening on port 8081, calls the index() method on the root class. The root class was set to:


at the bottom of that file. The index() method from the ReSTPaths1 Class looks like this, at the top of that file:

	def index(self):
		http_method = getattr(self,cherrypy.request.method)
		return (http_method)()

If we were to insert a print cherrypy.request.method statement before the return, we would see it set to “GET”.

getattr simply says: “get me the function name in self, matching the string “GET”.
it returns a reference to self.GET(), which is set directly below the index:

	def GET(self):
		return "In GET 1.."

Notice that the index() method has a @cherrrypy.expose decorator above it. This makes the index method callable by the public. The GET method does not have it, which means we could never invoke the GET method by typing:


If you try this, you’ll get a 404 Not Found error, because it’s not visible through the CherryPy interface.

GET() has to be invoked through index(), which means GET can only be called if an HTTP GET request is issued. If we posted form data to this same URL from, say, a form entry asking people for data input, we would need to add a POST method to this ReSTPaths1() class, to receive the POST data entered in the form fields.

Now back to our example:

In this example, no part of the URL or associated resources are dynamic, in either initialization or run time. This is fine, and suits the needs of most ReSTful CRUD interfaces.

Way 2: URL paths and associated components dynamically set once, upon dispatcher init/startup:

Now let’s say we want to determine the contents of the root, and therefore the URLs and associated resources for our ReSTful interface, dynamically during initialization/startup.

We can assign the root setting by using a Python metaclass to generate classes in our CherryPy startup code, and set the root components to each generated class. This goes beyond the average needs for CRUD access, but it’s such a nice implementation that I must show it off:

import cherrypy

class MetaCRUD(type):
	def index(cls):
		http_method = getattr(cls,cherrypy.request.method)
		return (http_method)()

	def GET(cls): return "In class ", cls.__name__, ', received a GET request.'

	def PUT(cls): return "In class ", cls.__name__, ', received a PUT request.'

	def POST(cls): return "In class ", cls.__name__, ', received a POST request.'

	def DELETE(cls): return "In class ", cls.__name__, ', received a DELETE request.'

baseCRUD = MetaCRUD('baseCRUD',(),{})
root = baseCRUD

dynamic_class = {}

for d in ['legacy_dbi','new_dbi','some_other_dbi']:
	dynamic_class[d] = MetaCRUD(d,(),{})


Here we’re using a metaclass, with CherryPy exposed methods, to generate a dictionary of dynamic classes. We set the root.classname = the_new_class by using the setattr() method.

After initialization, URL components and resources are fixed in this model. But wow, the awesome power we have during initialization, in 28 lines really rocks. I wrote this in 30 minutes, and realized again why I am so head-over-heels in love with this language.

When we hit these URLs:





We see this output:

In class baseCRUD, received a GET request.
In class legacy_dbi, received a GET request.
In class new_dbi, received a GET request.
In class some_other_dbi, received a GET request.

Let’s issue a POST request via curl, on the command line. The response is returned:

[gloriajw@g-monster ~]$ curl http://localhost:8081/some_other_dbi/ -d ""
In class some_other_dbi, received a POST request.

This model could be used for, say, reading the contents of the Postgres template1 databases list or the mysql ‘show databases’ command, and auto-generating a ReSTful CRUD interface for each. Access of each resources can be controlled via HTTP Auth methods. This is a great solution to providing, and restricting, legacy database access for new processes through a standard interface.

Way 3: Live, ever-dynamic determination of URL and associated component:

Some ReSTful URL models may need to be ‘run-time dynamic’, especially in the case where databases are dynamically created, and the associated resources per new database could vary. There is a simple example of a dynamic URL and resource model:

import cherrypy
import pprint

class ReSTPaths:
	def __init__(self):

	def client(self,*args,**kwargs):
		return "Your HTTP method was %s. Your args are: %s and your kwargs are: %s\n" \
		% (cherrypy.request.method, pprint.pformat(args), pprint.pformat(kwargs))

	def address(self,*args,**kwargs):
		return "Your HTTP method was %s. Your args are: %s and your kwargs are: %s\n" \
		% (cherrypy.request.method, pprint.pformat(args), pprint.pformat(kwargs))


This allows for dynamic URLs such as:






The output from this code looks like this:

Your HTTP method was GET. Your args are: ('address', '34567') and your kwargs are: {}
Your HTTP method was GET. Your args are: ('address',) and your kwargs are: {'client_id': '34567'}
Your HTTP method was GET. Your args are: ('client',) and your kwargs are: {'client_id': '34567'}
Your HTTP method was GET. Your args are: ('client', '34567') and your kwargs are: {}
Your HTTP method was GET. Your args are: ('anything', 'anything_else') and your kwargs are: {}

Notice that we only have keyword args (kwargs) when we pass a named parameter, such as client_id=34567

Let’s try a POST request from curl, on the command line:

[gloriajw@g-monster ~]$ curl -d "something_else=whatever_i_want" http://localhost:8080/address/anything/anything_else
Your HTTP method was POST. Your args are: ('anything', 'anything_else') and your kwargs are: {'something_else': 'whatever_i_want'}

In this code, the sky is the limit. You can place whatever code you like in these methods, dynamically creating classes and resources as needed, letting them only persist until the result is returned. This may add some inefficiency, but in exchange offer more secure network resources.

Code is attached, Enjoy!


Book Review: Pro PHP Security


ProPHP Security

Published by: Apress

Authors: Chris Snyder and Michael Southwell

Book Site | Sample Chapter: Preventing SQL Injection | Table of Contents

At first, I thought this book was all about cleaning your input variables and filtering your output, XSS attacks, SQL injections but I was most presently surprised to find that it was that and so much more! In fact, I would have called this “ProPHP Security and Administration” instead! It is absolutely fantastic. It really is about security in all of the facets of web development – from server, to code, to database to the system users.

The book is divided into 4 parts:

  • Part 1: The Importance of Security
  • Part 2: Maintaining a Secure Environment
  • Part 3: Practicing Secure PHP Programming
  • Part 4: Practicing Secure Operations

Here are some brief overviews of the sections and the tidbits I found interesting:

Part 1:

The first part is the shortest and gives a general overview the what and why of security.

Part 2:

The second is much more hearty and goes into detail about Shared hosts and why they are secure and how to make the more so. It even dips into alternatives for the traditional shared hosts and goes into Virtual Machines. This is valuable to not only to administrators but to PHP Developers. After reading this, I understand the “why” behind many of the things about shared hosting that I found frustrating.

One of the most important things I found in this chapter is how to maintain separate development and production environments. When I was helping to set this up at one of my past jobs it was a topic that I couldn’t find much information about. It also makes mention of version control, using wikis, bug tracking, sandbox and testing! Oh and here’s a concept…. pretend your live system failed — how well does your backup plan work?

How many times have I thought, I should make a cron job to back up my database to my home server every day/week? Have I ever done this? No! But now I have no excuse! Backing up a database and storing remotely is one of the sections in this chapter and code included! Fantastic.

There are chapters about Encryption theory and practice which I read several times to understand. It was interesting but it wasn’t something I have to do right now in my life, but I will return to this book to refresh my memory when I do.

Securing Network connections SSL and SSH, these proved helpful as I have become the “Reluctant System Admin” for one of my projects — partly because if they were to hire a part time person I’d rather they get a CSS person and I’d rather do the sys admin!

The Controlling Access section goes into details about using certificates with php, single sign-on, basic and digest http authentication … whoa this is some deep stuff! But good, when I was looking into this for a project a few years ago I couldn’t find anything helpful. It continues with then permissions and restrictions, a lot about Unix permissions and keeping things running where they should, securing databases and PHP Safe mode!

Part 3

Finally — the stuff that I thought the book would be about – validating user input, filtering output, preventing cross site scripting attempts, remote execution.. so much more to security than I thought! It talks about securing temp files, I always assumed the OS handled this and I didn’t need to worry.

Part 4

Ahh — Practicing Secure Operations… all you ever wanted to know about making sure your users are humans, verifying your users, setting roles for users, logging your users actions, preventing data loss, executing system commands safely, working with webservices and finally Peer Reviews! Sometimes it’s that extra pair of eyes that can see things you miss.

Something I find interesting – in the section about preventing data loss, it talks about setting a flag on records that are “deleted” and then making a db view of the “good” data and using that to select from. One of the things I like in Ruby On Rails is this “acts_as_paranoid” model option that does about the same thing. Neato.

Pro PHP Security is a most excellent read and so much deeper than my brief overview here. It will be a handy book on my shelf to keep me on my toes regarding security in all areas of web development, from the server to the code, to the users, to best practices of security you will find this is a helpful book too!

< DirectoryMatch > and regular expressions


I learned something new in Apache today that I thought I’d share with the group. You may already know this but always good to write stuff down.

I’m maintaining an application on a virtual host that uses a vhost.conf file to set php settings (such as auto_prepend_file, open_basedir, and include_path) for the application (rather than using individual .htaccess files). Initially we were setting the same settings for the entire application, and so we could use the Directory container in the vhost.conf file like this:

< Directory
/path/to/public/directory >

php_value auto_prepend_file /path/to/

< /Directory>

And then that file would be automatically prepended to every file in the app, so stuff like database settings were always available. But we’re integrating a second module that will need it’s own configuration files so I was trying to find a way to have the initial include work recursively for every directory *except* the new integrated directory. In short, I wanted: /path/to/public/directory/EXCEPT_FOR_NEW_DIRECTORY.

I learned that to do that you have to use < DirectoryMatch > and feed it a regular expression. You could also feed a regular expression to < Directory > but < DirectoryMatch > is intended for that purpose. It was a little more complicated than I’d thought to write the regex, since you can’t just write a regex that excludes an entire word — those end up searching for each character in the word, so if your word is [myword] your regex works on m,y,w,o,r,d — which is not what you want. I found an example that will check for the first three letters of a word (since I knew that would be enough for me, and b/c it was getting long) and tailored that to my purposes. I also found one for negative lookbacks, but that was more complex than I needed.

So I ended up doing this:

< DirectoryMatch
[^c]m[^e]|[^c][^m]e|[^c][^m][^e])(w*)" >

-- do stuff

< / DirectoryMatch>

And then I had another simple < Directory > container for the included module.


Later it was pointed out to me that “if it’s only some options you don’t want you could subtract them:”

< Directory
/usr/local/psa/home/vhosts/ >

Options Indexes

< /Directory >

< Directory
/usr/local/psa/home/vhosts/ >

Options -Indexes +ExecCGI

< /Directory>

I don’t know a ton about apache configuration, so I went with my first method, which was working. If anyone can chime in and further explain the latter example with the subtraction, that’d be great.