which is a bit of code quite common in an authentication filter. The problem is it will throw a ThreadAbortException as soon as you put your code on a live site resulting in the error page for anyone who is not logged in. This is probably not what you want since you are attempting to redirect them to the login page.

Now it is a little unfair to say that it’s an issue because that is the intended functionality. But it doesn’t fit well with MVC controllers, especially since Microsoft’s official suggestion is to set the endResponse flag to false. That is just downright misleading since your controller action (which the filter just decided you can’t access) is still executed after the filter fails authentication – resulting in the action code being executed anyway whilst you see the login screen on the browser and assume it all went swimmingly! Meanwhile those files that this user shouldn’t have access to got deleted.

Yeah, that’s what I just did during testing whilst proving to myself that you can’t fake the URL as a non-registered user. Imagine my surprise. It’s true that the chances of a malicious user actually working out the URL might be low, but that’s no reason to leave the door open.

Oh, and your unit tests probably won’t catch this because the filters don’t get executed by the unit tests. But I digress…

To cut a long story short, this bit of code in your base controller (assuming you have one, otherwise stick in in all of the controllers) will prevent the issue:

So here’s the problem – you create a website that allows the upload of images (or any file types for that matter). It’s very likely you’re going to want to limit the size of those uploads or you’ll end up in a world of pain when your users go and use up all your disk space. By default IIS allows upload sizes of 4Mb which is ample for image purposes. However, if someone uploads a file above that size you’re likely to want to notify them by telling them gently they’re an idiot for not reading the note above the file input field and then allow them to reselect a file.

But you can’t because the requests never gets to your page. IIS simply drops the request and seems to respond with nothing at all. That leaves the user looking at a ‘Web site could not be found’ error, which is misleading and just plain wrong.

And this is the situation I found myself in. Simply put, you can’t catch the HttpException in your code and recover gracefully. Unfortunately the vast majority of people out there believe the answer is to increase the maxRequestLength in web.config. How can that be considered a solution? It’s like saying the way to deal with traffic congestion is to double the size of every road. Someone, somewhere will then try and upload a file that is even bigger and the problem repeats itself.

I spent a long time looking for a solution and eventually came across a little trick which you can pull in your Global.asax:

Thanks to this guy for the hard work.

It seems to be about the only place in the code that you can do anything about the error. What it’s actually doing is reading in the whole of the request even though it is over your maximum request size. Once the whole request has been read you are able to make a response to the calling client, in this case a redirect to an error page. It’s possible that you could take this further and carry on with the page the user originally intended to work with, catching the error and displaying it there. But I’m too burned out to try that right now and this solution works fine for me!

But frameworks change during development and you come across the issue that all of the top hits for your query are based on previous versions. When that previous version did it differently you’re stuck! I had this problem today when trying to create strongly-typed views. I love strongly-typed anythings, but I’m just a sucker for having a project that is more likely to work when another developer makes an edit and doesn’t bother fully checking the effects of their changes. It’s another safety net, and I’m a sucker for safety nets as well.

So, this is how I did it in bite-sized chunks. First the controller function:

Next I created a new view by right-clicking the above method (bear in mind that I’m using Visual Studio 2008) and checking the ‘Create a strongly-typed view’ before entering the full name of the object type (ContentClass). That produces an aspx.cs which looks something like this:

So far so good, but where I really came unstuck was actually using this in the view. Turns out it’s simpler than ever. All you need to use is the ViewData.Model parameter, which is automatically typed to whatever you set the view up as previously:

All that I have to do now is pass that through to a UserControl. I’m assuming I can strongly-type those as well. We shall see.

Or at least that’s what you’d think. You know how it is – you get it all working on your lovely development machine and then once the decision has been made on where to host the final result, you upload your application and…bang…

HttpException (0x80004005): The incoming request does not match any route.

Oh yes, that works so well.

Suddenly that belief that, finally, someone has produced a framework which is so nicely integrated with your target platform comes crashing down around your head as you weep softly into your keyboard. No, ASP.NET MVC is not actually supported on anything under IIS7. Does your host offer IIS7 at the moment? I guess not.

Now don’t get me wrong, it does work on IIS6 but you have to mangle it a bit and unless you pay a fortune each month for access to your own virtual server then you’re likely to lose those pretty urls. That’s not the same as being supported. For those that have spent the last two hours Googling and still getting the same problem, here is the man with the answer:

http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx

Simple, I thought – text-align:right in the CSS and the jobs a good ‘un. Well yes, you would think so. The fact of the matter is that text-align:right is only supposed to apply to block level elements (according to the CSS2 specs), although it isn’t quite implemented that way in all browsers. So, add display:block in there as well just to be on the safe side:

Left Align: <input style=”padding: 0px; text-align: right; display: block” type=”text” />

Job done! Well, not quite if you are viewing this in Internet Explorer 7. Click in the input field which is aligned to the right and no cursor displays at all! I must be tired today because this took me ages to work out and I found no reference to it anywhere in the web. For some reason the cursor is there – it’s just off to the right a little too far. I say ’some reason’ when I now know that the actual reason is that the padding is set to 0px. The reason for this happens to be because it has inherited the property from other elements in my form layout, but in this example I have added it specifically. Add a little padding to the right and hey presto:

Left Align: <input style=”padding: 0px 1px 0px 0px; text-align: right; display: block” type=”text” />

That’s just strange. Zero padding displays the cursor on the left, but not the right. Except in Firefox, which just shows it correctly in either case.

So I do think that it’s great for web applications, but not necessarily for web sites. Clean urls have many touted advantages over controller/action urls for a web site. I’m not sure how many are true (things like Google favouring them seem like a good reason, if that is actually the case) but for me it’s best simply because they are not controller actions. A ‘contact me’ page is a ‘contact me’ page. It’s not really an action on a particular controller in your application. An ‘about’ page is similar – it just seems wrong to say ‘about’ is an action on ‘pages’. Well, it does to me anyway. Whilst I usually write web applications there is almost always a web site component like this to them and I think it’s fine to seperate those two concepts even when they’re on the same site.

Now it’s true that you can write static pages directly to the webroot, but my clients almost always want some management control over those pages. As much as I’d like them to have to come back to me every time they want to change a word it just doesn’t seem particularly fair and just harms my chances of repeat business! All of the other solutions I came across just seemed rather complex and often slightly dodgy. So I came up with a simple solution of my own that works fine.

Basically you add an entry to routes.php for each of these pages:

This will redirect any call to ‘/contact’ to ‘/pages/contact’, but without giving that fact away to the user. It’s true that you can’t now have a controller called ‘contact’ but then you wouldn’t want one anyway (the main reason being controller names should be plural when following the Cake conventions!). You can add as many of these lines as you like. If you end up with more than 2 or 3 you might want to question whether those pages should have been part of a controller!

So I did the best thing I could think of and ignored it, but when I came to creating the form to edit existing values I just ended up getting strange results. The checkboxes seemed to have a life of their own, checking and un-checking at will between post-backs. Google came up with several posts about the general problem most people come across with checkboxes – the fact that they post back nothing if they are not checked, but it took me far too long to actually put the strange hidden input field and this standard behaviour together. In my defence, there is very little documentation on this (that I could find) for CakePHP.

I did a bit of debugging and discovered that I did always get a value posted back – sometimes ‘0′, sometimes ‘on’ and sometimes ‘-1′. The ‘on’ I’m used to as that is the value posted back by a checkbox when it is actually checked, but the others seemed a bit random. After much nashing of teeth and a lot of keyboard punching I think I have it, or at least I have a good enough idea of what they are doing to get it to work for me.

The hidden input field has the same name as the checkbox meaning that any value it contains is posted back if the checkbox is unchecked when the form posts. Nifty trick. If the checkbox is set to ‘unchecked’ when the form is rendered then the hidden field is set to ‘-1′, otherwise it is set to ‘0′. The result is that the value posted back is ‘on’ if the checkbox is checked by the user, 0 if the checkbox is unchecked by the user (and was originally checked when the form rendered) and -1 if the checkbox is unchecked (and was originally unchecked when the form rendered).

Make sense? I hope so. It’s actually pretty useful since you can tell what the user did rather than just knowing the state when the form is posted. Since this is not the value we want to stick in our database (well, -1 isn’t anyway) we need to do a bit of manipulation at the controller end. Rather than just mapping the checkbox to the model as you would probably do with a text field it is best to have some sort of interim parameter which can be checked and the desired value set on the model. This is my effort. I don’t think it’s too pretty but it’s late, I’m tired and it works.

So, my fake value ‘big_rock_checked’ gets the posted value from the form and if it is ‘-1′ I know there’s no change to the value and can ignore it. Since it doesn’t get set on the model it doesn’t change the db value. If it’s ‘0′ or ‘on’ I just set the model value and let the framework deal with it.

I think some sleep is in order after that one

I found that the issue was definitely down to one line in the root .htaccess (which was unmodified from the original CakePHP download):

Unfortunately my cheaper hosting doesn’t allow me access to the error logs so it was difficult to diagnose the problem. By 11:00 last night I was certainly not in a good mood and no closer to an answer. I managed to Google plenty of references to similar issues but none solved my problem.

This morning I resorted to the hosting company themselves and within an hour they came up trumps! My thanks to Rob at VirtualNames support who not only worked it out, he even changed the file for me!

It looks like the problem is that the mod_rewrite rules don’t like fastcgi, which is the preferred option for this hosting account – it seems to try and redirect the internal URLs for fast cgi causing a rewriting loop. VirtualNames support felt it would probably work if the PHP mode is switched back to module mode, but they also came up with a fix to the .htaccess in the domain folder to (the root .htaccess for the CakePHP installation):

This stops it trying to redirect the fastcgi internal access urls, and appears to cure the problem. It looks like the other .htaccess files do not need changing. .htaccess and rewrite rules are still a bit of a black art to me. After this they are going on my list of things to pick up!

I can also recommend VirtualNames as a budget hosting solution should you need one. Their support people actually do…erm…’support’

On the whole it has gone fairly smoothly, though it hasn’t been entirely without problems. Here is the detail of what I have set up and where I came across issues. It might help someone if they come from a similar background to me of PC development.

Apache 2

Thanks to it already being set up on OS X this was no bother at all. System Preferences > Sharing > Services and set Personal Web Sharing to on. You should be able to browse to your home page straight away and it even gives you the URL of your home page at the bottom of the tab. It’s little touches like that that really make you think Apple love you!

Don’t think you won’t come across set up issues later though. It will need some tweaking to get it running properly with the other stuff coming up.

PHP

It doesn’t really matter what version as long as it’s 4.3 or later. Before that it was not quite so easy to install PHP on a Mac, but now it’s a doddle. Apple have a nice tutorial:

http://developer.apple.com/internet/opensource/php.html

MySQL

I thought this would be the most difficult area but, again, Apple have a nice tutorial:

http://developer.apple.com/internet/opensource/osdb.html

I also installed the MySQL GUI tools. To be honest I still think they’re a bit poor compared to other admin tools for other databases (or even for MySQL for that matter). For instance, MS SQL Server’s management console is far superior, in my opinion. Unless you’re really good with command-line SQL (and I’m not even though I’ve worked with databases for over 7 years!) then the tools will be necessary for setting up databases and database users. As I’m sure you know, it’s never a good idea to use root for applications. That reminds me, the first thing you should do is give root a password as it will be blank by default.

CakePHP

Not that you have to install CakePHP, it just happens to be something I’ve used on a couple of projects recently and contains some quite complex components. I figured that if I could get this up and running my environment would be ready. The installation is fairly straight-forward, but certainly not without problems. This was not necessarily down to CakePHP or any other component, just the set up between them.

The first thing you really should use with CakePHP is .htaccess which is turned off by default in Apache. However, what I didn’t know is that changing the setting for AllowOverride from ‘None’ to ‘All’ in /etc/httpd/httpd.conf is not enough. There are also your local configuration settings in /etc/httpd/users/<username>.conf which require the same change.

That certainly made a difference as I immediately received 403 forbidden errors – ‘You don’t have permission to access /’. It turns out, after some trawling around, that the issue is with the FollowSymLinks option not being available. Check that ‘Options FollowSymLinks’ is enabled in your personal .conf file. Mine now looks like this:

<Directory "/Users/Jason/Sites/">
    Options Indexes FollowSymLinks MultiViews
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

I also had problems with Apache locating my files, probably because I was working directly from my /Users/ folder and Apache was set to use /Library/WebServer/ since I’d left it at the default. Rather than mess around with that I just created a link folder from the console. This seemed to sort the problem nicely.

ln -s /Users/ /Library/WebServer/Users/

Finally I had my web application running, .htaccess redirection was working nicely and the right files were being served up on request. But then it was failing to talk to the database, spewing out ‘Can’t connect to local MySQL server through socket …’. That took me a while to work out since most of the time Google searches just tell you that the MySQL db server hasn’t been started. I knew it had otherwise the client tools wouldn’t have been able to do much. It turns out that the database configuration file in my CakePHP application was incorrect. Not in an obvious way either. It just happens that you cannot refer to the local database as ‘localhost’ which works fine on my Windows environment. If you get the problem try 127.0.0.1 instead.

database.php:

And that seems to be it at the moment. I haven’t done much actual work yet so I’m sure things will crop up as I go along. Hopefully I won’t forget these issues the next time though.