Drupal login and SSL

After the last article, I discovered that the Drupal framework, while it works perfectly within a SSL context provides little in the way of helping developers direct their users into the secure site. In our application we provide some content to the public at large, but we also require the majority of the site in a private context. This proved challenging because we didn’t want the expense of redirecting the common Joe Browser into the SSL when their casual experience wouldn’t require the overhead. Fortunately, after my last lesson in mod_rewrite I figured a clever approach to pushing authenticated users into the secure context.

RewriteCond %{REQUEST_URI} ^/user
RewriteCond %{SERVER_PORT} ^80$
RewriteCond ^(.*)$ https://example.com/$1 [L,R]

Since Drupal uses the same login section of the site, I was able to push the user under SSL when they went to log in. This doesn’t necessarily prevent them from dropping out of SSL when theyenter the site, but it does mean that they will end up in the right place at the outset.

May 3rd, 2008 | Programming | 2 comments

Great minds, or how I learned to love mod_rewrite.

Today we rushed to push out another site for our primary customer’s new facility opening tomorrow. Since it’s under the same umbrella organization we thought it best to use the subdomain form of the URL, rather than shoehorning it under the primary www site. Of course, within 10 minutes of the new users visiting the site we were already finding users who could not help but add the “www” even though we never mentioned the prefix. So I decided that we should redirect the users to the “correct” form of the subdomain. After a little research, I discovered the joys of mod_rewrite solving this specific issue.

Most sites want users to use the nearly ubiquitous “www” prefix. As Jeff Atwood mentioned in his post on the topic. It has become so pervasive in the web sector that it is nearly a non-entity; if you mention it you are being redundant. As Jeff argues, with the power of mod_rewrite penetrating even the ivory towers of IIS with add-ons like ISAPI Rewrite, we as developers must shoulder the responsibility to conform to our users behavior. It is so simple to gracefully handle the requests that not being flexible for our users is the ultimate crime.

In my experiment I had to tackle removing the “dub-dub-dub” prefix and sending the user the the stripped URL without. In most circumstances, the site maintainer will add the following to either the httpd.conf or to an .htaccess

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [L,R=301]

The RewriteCond is effectively our if statement. If the requested host begins (^) with the world famous “www.”, followed by any number of characters “(.*)”, without regard to character case (”[NC]“), then go to our RewriteRule.

The RewriteRule then changes the whole mess into the previous argument without the “www” mess and informs the browser that the request is permanently redirected.

These two short lines change bizarre “http://www.kire.notneb.net” into the familiar “http://kire.notneb.net” once again righting the wrongs of “www” misuse.

I also found that even great sites like del.icio.us don’t permit the misdirection from “www”, which makes me wonder how far we have to go in our quest for better URL management.

May 1st, 2008 | Programming | No comments