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:
Everyone knows that when you have a text box which accepts a number, it should automatically right-align the text content. Well maybe not everyone, but accountants certainly do and if you’re writing an application for an accountant it just won’t look right unless the values are right-aligned.
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:
Right Align: <input style=”padding: 0px; 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:
These days I always seem to find myself writing installers for clients using WiX. What usually happens is I get there to find they are really struggling to maintain their current installers, more often then not in InstallShield. So I go and tell them they should try WiX since it has so many advantages over certain other products. For a start it’s actually maintained by several Microsoft guys and enjoys a big support community. Also since the source code is written in XML it is much easier to check in to source control and maintain.
Anyway, to cut a long story short, my evangelising on the subject usually ends in the words ‘here you go then, write an installer for that’. And so I end up with the job yet again.
That’s not to say it doesn’t have its issues like so many other things in the world of software development, especially when you end up writing some monster installer that installs a web-client, web-services, windows-services and the odd database or two.
Today’s issue was ConfigureIIS which is a custom action executed if you are creating a <WebVirtualDir>. Unfortunately even if you are not installing the web component that needs IIS to be configured it will still attempt to execute ConfigureIIS which causes an error to appear if IIS is not installed. Just having a web component in your installer is enough to fire it off.
Looking on the WiX mailing lists it seems that it is a known issue and the only way around it currently is by modifying and recompiling the source code for WiX itself. Not a lot of fun when you just want to write an installer and it takes you away from the currently released code, which I find it is best to avoid when working for other clients.
However, in the process of modifying the source I found the property SKIPCONFIGUREIIS. Set this to true and it no longer runs the ConfigureIIS custom action. Obviously you need to make sure it’s only turned off for the relevant features of your installer. It’s just a shame they didn’t make it a little more widely known!
To be honest I could have kicked myself since I already knew of the SKIPINSTALLSQLDATA for turning off the database activity when not required. That one is a little more published though.
Since I got the Mac a couple of months ago there is one thing that keeps bugging me; connecting to my server is not particularly reliable. Dropped connections seemed to be pretty much guaranteed half way through a job that involves anything more than a couple of Mb of data. Since I tend to use the server for automated backups of my other machines it just hasn’t been happening for the Mac. Slowly I’ve got more and more concerned about having no regular backups.
A chance comment I came across whilst Googling for something else seems to have cleared up the issue. It seems my technique of using the Network utility in the Finder was the main issue. It is certainly the simplest option and most people seem to use it for that very reason. The trouble is it doesn’t always get the protocol right. You can check this by creating a connection to your server (in the finder choose Network and then browse to your server and connect to a share), selecting the new connection and then checking the info (Apple key and I). Mine shows up as:
cifs://my_server/backup
Since my Linux server uses Samba for the network shares it’s far better to connect using the Samba protocol:
smb://my_server/backup
The easiest way to set this up is through the ‘Connect to Server’ utility in the Finder. This also stores your server connections for easy future access. You should be able to simply type the connection string in and then connect at will. Hopefully you’ll see a much more stable connection in future.
(An extra tip – once you have the connection set up you can automatically connect at login by adding it to the list in System Preferences->Accounts->Login Items)
I’ve been using CakePHP for quite a while now with no .htaccess issues at all, either running locally or on hosted sites. That all changed last night when I couldn’t get it to work at all on one of my budget hosting sites. Instead of my application all I saw were 500 Internal Server Errors.
I found that the issue was definitely down to one line in the root .htaccess (which was unmodified from the original CakePHP download):
RewriteRule (.*) app/webroot/$1 [L]
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):
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule ^$ app/webroot/ [L]
RewriteCond %{REQUEST_URI} !^/cgi-bin/
RewriteRule (.*) app/webroot/$1 [L]
</IfModule>
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’
I’ve been using CakePHP for quite a while now with no .htaccess issues at all, either running locally or on hosted sites. That all changed last night when I couldn’t get it to work at all on one of my budget hosting sites. Instead of my application all I saw were 500 Internal Server Errors.