Shaun Mccran

My digital playground
 
10
M
A
Y
2010

The SEO way to safely redirect a Page or folder using 301 redirects

In a recent project we are restructuring a site to be more intuitively architected. But what impact will moving the directories or pages have on all that hard earned Search Engine Ranking Optimisation work?

This article deals with how to safely redirect users from an old page or folder to the new URL, and keep Search Engine's informed of your changes without leading them to dead content (Dead content is bad and will adversely affect your Site rankings).

[More]

 
28
J
A
N
2010

Passing url variables through Isapi re write - Regular Expression

One of the more common tasks in ColdFusion development is passing variables through the URL string. We are all familiar with the idea that the question mark (?) denotes the url query string start, and that name value pairs are separated with the ampersand (&).

I usually avoid using this in display templates, as it isn't great exposing your internal site workings to customers, and with Fusebox it is very easy to pass the URL variables to an "act_" template and remain hidden.

What happens when you want to use dynamic url variables with a URL re writing application like Isapi re write? I've been using Isapi re write in some FuseBox framework application, and it is relatively easy to set up a rewrite rule, as shown below.

view plain print about
1RewriteRule home(/) index.cfm?fuseaction=circuitname.circuitfunction

Where the url /home/ would actually serve up the content specified in the fuse specified. But this is hard coded. What about dynamic variables?

We can create a regular expression to handle the translation of the variables.

view plain print about
1RewriteRule destination/(.*)/(.*)/ index.cfm?go=circuitname.circuitfunction&$1=$2

We use a similar URL, but append the dollar ($) 1 = dollar ($) 2 string. In the re write rule we specify that appended variables are transposed into the string using the slash (/) as a separator.

So as an example we could pass a product id of 24 into the rule like this:

view plain print about
1www.siteurl.com/cart/productId/24/
2RewriteRule buy/(.*)/(.*)/ index.cfm?go=cart.buy&$1=$2

It would be rewritten to the more familiar url string. A handy way of continuing to mask the url.

 
22
D
E
C
2009

Using Isapi / Apache rewriting to mask URL strings, for cosmetics and security

One of the more recent additions to my Coldfusion frameworks is masking the more ugly URL's using Isapi rewrite. In this article I'll be using Helicon's Isapi ReWrite, but Apache re write works in much the same way.

Usually in your Coldfusion frameworks, most other technologies as well, you are passing around a variable or two to control the page content, and more often than not it is in the url. It never looks particularly clean if your URL has a long name value query string behind it, like this:

view plain print about
1http://www.mysite.com/index.cfm?variable1=pagename&location=england&value=7

Cosmetic reasons

So for two reasons URL rewriting seems like a good idea.

Firstly to mask those ugly URLS with a url rewriter. On a basic level this will re write specified request to the URL you tell it to, taking your ugly list of name value pairs and changing it into a user friend URL. If you are pitching this to a client this looks a lot more professional.

Security reasons

Secondly there is an added security benefit here. The URL gives a lot away about a website, like what the code base is, and is potentially a window on the internal workings of a website. Take a normal FuseBox application for example. The normal URL might be:

view plain print about
1www.mysite.com/index.cfm?fuseaction=controller.action&othervalues=values

From here it is very easy to start messing around with the controller names, trying to dig out an 'admin' controller, or other common function controller. Similarly adding values to pages where it is obvious a Query has been fired is an easy way of testing of the developer is using 'cfQueryParam', with potentially disastrous results.

Along the same lines it is quite simple to inject form values into the URL (like this http://www.mccran.co.uk/index.cfm/2009/7/30/Cross-site-Script-hacking-using-the-GET-method). By masking the URL and the values you make it considerably more difficult to do this, after all if you can see or get to the URL, how can you fool around with it?

So far I am implementing a rewrite script that will rewrite URLs into friendly strings, here is a modified version of the .htaccess file I'm using.

view plain print about
1# Helicon ISAPI_Rewrite configuration file
2# Version 3.1.0.68
3
4RewriteEngine on
5RewriteBase /wwwroot/
6
7#generic
8RewriteRule requestID/(.*)/(.*)/ index.cfm?decryptURL=$1&params=$2
9
10# site pages
11RewriteRule home(/)? index.cfm?go=controller.home
12RewriteRule contact(/)? index.cfm?go=controller.contact
13RewriteRule login(/)? index.cfm?go=controller.login
14RewriteRule privacy(/)? index.cfm?go=controller.privacy
15RewriteRule about(/)? index.cfm?go=controller.about
16RewriteRule faqs(/)? index.cfm?go=controller.faqs
17RewriteRule search(/)? index.cfm?go=controller.search

This code starts off by turning the rewriteEngine on, then setting the rewriteBase, this is typically your webroot, or the root of the site the file is for. Then it rewrites any URL params to the URL string.

The main part of the code is where we set individual rewriteRule's for each URL. The first example (home) looks for any URL requests to the 'home' string, and re writes this to the URL in the regular expression (index.cfm?go=controller.home). Pretty straight forward really.

There is a lot more you can do with this, and hopefully I'll get to explore rewriting in more depth in the future.

 
16
D
E
C
2009

Using Isapi rewrite to serve up non existing templates

I was discussing some ideas for an application framework this morning with the team, and one of the issues we hit upon was having a common directory for templates, but serving them up as if they were from a different directory.

The idea is to have one instance of a reusable skinnable template, that appears to live on several sites.

IE all the content lives in "webroot/content/templateName.cfm", but is actually served up by many sites, IE "127.0.0.1/site1/template1.cfm", "127.0.0.1/site2/template1.cfm" ... etc

In this way they can be re skinned or adapted as needed, and they aren't database driven. The main stumbling block for the discussion was the need to actually create blank versions of each of the named templates, in each of the sites, as ColdFusion server would error on the request.

I spent twenty minutes trying to work it so that my Application.cfc's onRequest or onRequestStart method would intercept the request before it was actually made, but that just wasn't working. My other idea was to use the onMissingTemplate method, but the server is only running ColdFusion 7, so that was a no go (I figured I could catch the missing template request and just re path it, although I'd have to assess if that was really inefficient due to almost every page request logging as failed).

My eventual solution was Isapi rewrite. I am re writing all the requests to the same template, and just passing in the template variable. In that way I can request pages that don't actually exist, but they appear in the url.

Create an index.cfm template like this:

view plain print about
1<h1>I am the index page</h1>
2<ul>
3    <li><a href="page1">Page 1</a></li>
4    <li><a href="page2">Page 2</a></li>
5    <li><a href="page3">Page 3</a></li>
6    <li><a href="page4">Page 4</a></li>
7</ul>
8
9<cfdump var="#url#">
10<!--- write a handler to go get the url var passed in --->

For this example I am using the free version of Helicon's Isapi rewrite, you can get it here: Link to Helicons Isapi re write

In the example below I have altered the first page link to look like it is actually a .cfm template request, just in case you want the url string to have a .fileextension look to it.

view plain print about
1# Helicon ISAPI_Rewrite configuration file
2# Version 3.1.0.68
3
4RewriteEngine on
5RewriteBase /mywebroot
6
7#no physical page testing
8RewriteRule page1.cfm(/)? isapitest/index.cfm?p=page1
9RewriteRule page2(/)? /index.cfm?p=page2
10RewriteRule page3(/)? /index.cfm?p=page3
11RewriteRule page4(/)? /index.cfm?p=page4

So when you fire it up and test it you just see /page1, /page2 etc, and the pages don't actually exist.

I'm not experienced enough with Isapi rewrite to know if there is a downside to this, but bookmarking in a browser still works correctly, so I can't see an issues at present.


This content is purely my opinon, any offence or errors are unintentional, please comment your views appropriately
Site Credits
Aggregated by ColdfusionBloggers.org Powered by Coldfusion

Technology & Science Blogs - BlogCatalog Blog Directory Blog Directory & Search engine