Today we had a mini site which the promotion had completed, but the site was to stay live with a few of the content pages staying live for people who come to view it.

Because the site was only a few pages there isn’t a CMS back-end, it’s just flat ASPX pages are stored in a single folder.
The problem is, that the pages which need to be available are also in the folder which the pages which are not longer accessible are.

There is a few ways in which I can take down the pages which people aren’t meant to access, firstly I could just delete them. That’d work, but that’d be a 404 error which isn’t really a good user experience (I could set the 404 redirect to be the home page, but the browser would still receive a 404 HTTP status).

So the next option is URL Redirection, lets crack out our UrlRewriting.config file and set up a rule. We’ll start with a rule like this:

<add name="RedirAllIndexedPagesToDefault" 
   virtualURL="^(.*)/pages/(.*)" 
   destinationUrl="$1/default.aspx" 
   redirectMode="Permanent" 
   redirect="Domain" 
   ignoreCase="true" />

There, that’ll handle everything in our pages folder, but it doesn’t help with the pages which I want accessible. Say the pages I want accessible are TermsAndConditions.aspx and PrivacyPolicy.aspx, but I don’t want Entry.aspx accessible.
It’s just a matter of modifying my virtualURL to be a bit stricter, so now it looks like this:

<add name="RedirAllIndexedPagesToDefault" 
   virtualURL="^(.*)/pages/(?![TP.*])(.*)" 
   destinationUrl="$1/default.aspx" 
   redirectMode="Permanent" 
   redirect="Domain" 
   ignoreCase="true" />

Now you’ll not be able to get to Entry.aspx, but the other two pages will still work just fine.

Sure it’s not great if you’ve got lots of pages (and if you did have lots of pages I’d hope there was a CMS to deal with it), but it’s good for mini sites which you want some pages but not others in a folder accessible.

After foolishly pulling out my hair trying to find out why my wildcard mapping was disappearing in IIS 7 using classic pipeline mode, i realized it was my own fault!! I followed the instructions on this site: http://learn.iis.net/page.aspx/508/wildcard-script-mapping-and-iis-7-integrated-pipeline/ and unfortunately just skipped over the message about how this modifies your web.config… oops! So basically, every time I deployed my handler mapping would be removed… Doh!

Unfortunately, the method to add a wildcard mapping in this article will actually remove the inheritance of standard handlers from the root of IIS and your machine.config and just make copies of them. This might not be the best approach, but i suppose sometimes it’s necessary. We only need the wildcard mapping for URL Rewriting so i decided to see if i could just simply add the isapi wildcard mapping only, have the rest of the handlers inherit from the root and see if it works… turns out it does!

So instead of having to modify IIS itself, i just needed to add this to my web.config:

<handlers>
	<remove name="ASP.Net-ISAPI-Wildcard" />
	<add name="ASP.Net-ISAPI-Wildcard" path="*"
	verb="*" type="" modules="IsapiModule"
	scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll"
	resourceType="Unspecified"
	requireAccess="None"
	allowPathInfo="false"
	preCondition="classicMode,runtimeVersionv2.0,bitness64"
	responseBufferLimit="4194304" />
</handlers>

Too easy! No fussing around with IIS and now at least i won’t override my changes accidentally.

The other day Shannon was griping about a problem he’d come across when editing a user in Umbraco (a back-office account). When ever he clicked the Save button nothing happened, unless he’d gone and edited the Username field as well.

Today I noticed the same problem, I was trying to edit a user (I was changing the applications they had access to), I’d click save and nothing would happen! There was no error, there was no message from Umbraco.
It was as if the Save button was disabled.

And then it hit me, I was using Firefox and I had saved the username/ password combination when I logged into Umbraco.
That makes sense, the error seemed like some kind of client validation had been failing, but there was nothing obvious to me.
Then I realised that the password fields for the user details were hidden, so I clicked the Change Password link and look there, I have an error saying that my passwords don’t match.

Because I’d saved the username/ password in Firefox it was kind enough to auto-complete one of the password fields (using what ever algorithm Firefox does to detect password fields), but then there was nothing in the confirm field, causing the compare validator to fail.

So I cleared the field and clicked save, and all is well.

But why did it work when we changed the username? Well then Firefox detected that there was no password for that user, so it cleared the field, and the compare validator passed (it don’t compare empty fields).

Lesson learnt – be careful when you’re storing passwords :P