I've just been working on a personal project that requires a log in framework. My basic two use cases for this were:

• Non-authenticated user goes to a protected page.
  • They should be prompted to log in, and then sent to the page they originally requested after successful login
• Non-authenticated user clicks the "login" link while on a non-protected page.
  
  • After logging in they should be returned to the page they were on.
• Authenticated user goes to a page
  • Display the page.

I'm using Mach-II for this project, so I could easily send the user to the correct page (aka "event") using announceEvent(). However, I opted to use <cflocation/> to do a 301 redirect instead. I see two main benefits in doing a redirect:

1. Let's assume for example that the page a user lands on after logging in is one that updates frequently and the user decides to refresh the page to get the latest content. Without doing a 301 redirect, the user would be resubmit their login information (after being warned by their browser) and be re-authenticated by the application. There's no need for that, and it's just annoys the user and does unnecessary work behind the scenes.
2. Let's imagine the user logs in and then browses to a couple pages before walking away from the computer. Someone could then come along and try browsing around as that user. If the user's session is still live, then there's not much that can be done. But what if the session has expired? The evildoer would try to load one page and see that the session has ended. Though it may seem unlikely, they could then technically click back a few times in the browswer and then refresh at the right point to re-post the username/password and create a new session.

Of course, there are many other cases where you must, at the very least, redirect after a post. Most notably are online transactions (prevent someone from buying something twice).

That led me to to the question: Is there any reason you shouldn't ALWAYS redirect after a form post? I'm thinking if there ever was an instance, then GET should've been used instead (search pages, for example).

A couple weeks ago Banana Republic had a 30% off anything sale, so I took the opportunity to order a few items that I was eyeing for the fall anyway. One of the items was a brown cotton moleskin jacket. I was pretty excited about it. Unfortunately two days after placing the order I got an email stating that the item was out of stock. I was pretty dissapointed.

I'm not sure what kind of inventory management and shipping operation GAP, Inc. has going on, but it seems that this day in age, they shouldn't be selling items that aren't available, but I supposed mistakes can happen when you're trying to manage that much inventory.

I was in the store today returning one of the shirts I bought on that order when I noticed the jacket on one of the mannequins. I quickly asked if there were any more in the store, but that was the only one and it happened to be a small (I'm a medium). The store personnell were very helpful and managed to locate my size at another store (it was the last one remaining).

In the end it all worked out, and I actually got it for about $6 cheaper than the original 30% off would have gotten me--not enough to make up for the hassle of driving to two stores though.  I'm left wondering though why Banana Republic can't check the inventory of stores near me when they're unable to fulfill my online order? The clerk at the first store I visited was able to pull up the inventory of another store, so technically the system is mostly in place already.

An email stating that although my jacket was out of stock online, I could pick one up at a store nearby would have left me thoroughly impressed...instead of dissapointed.

It's difficult to come up with a cheaper and more scalable way to acheive long-term customer satisfaction than that.

By the way, as I look at BananaRepublic.com right now, the sweater they have featured on the men's main page goes to an "out of stock" page when I click on the "get it now" link. Nice.

The much anticipated Google Chrome just went live this afternoon, and I've just installed it and played with it a little bit.

So far there's nothing that really blows me away. It's probably too early to be a viable alternative to Firefox/Safari/Opera, but I'm sure there's still a lot to be seen from Chrome in the months to come.

Not to much surprise, the install asks if you'd like to transfer your settings from firefox (although you must close firefox first).

Read more...

Yesterday a co-worker sent out an email about Mozilla's newest peice of work, Ubiquity. It's not often something comes along that changes the way you work throughout a day, but Ubiquity clearly falls into that category.

It's hard to explain what Ubiquity does, because it does so much. I suppose you could say it puts commonly needed functionality at your fingertips, within the firefox browswer. Ubiquity is best explained with examples. At it's core you can do the following with simple commands:

• Look up a definitition
• Check the weather
• Check your calendar
• Add something to your calendar
• Spell Check
• Perform a calculation
• Insert a map into an email

There's a nice tutorial that will get you started quickly. I've only been using Ubiquity for a couple days, so it's still not second-nature, but it will be soon. It's great at making all those common little tasks throughout the day just a little bit quicker. It's hard to imagine anyone not finding this tool useful.

I was also pointed to a similar tool for the desktop, called Enso, which Ubiquity is based on. The installer wasn't working when I tried to install it earlier today.

I mentioned previously that I recently installed BlueDragon and have Apache set up to pass off .cfm & .cfc request to Tomcat using mod_jk.

Tonight I was trying to set up some rewrite rules using Apache's mod_rewrite module. However, it resulted in Apache serving up my cfml source code rather than passing the request to Tomcat. It didn't take long to realize that as a result of my new friendly urls there was no longer a .cfm/.cfc extension.

I modified the JKMount rule to be generic enough that any request would be passed to Tomcat:

This worked, in that it got the request sent to Tomcat, however it resulted in an ugly 404 from Tomcat. Tomcat wasn't aware of the url rewrite. After some googling I found that recent versions of Tomcat changed a default setting that prevented forwarding of the rewritten url. I added a line to my httpd.conf file to re-enable that:

It still wasn't working.

Later it occurred to me that that if I used the [PT] flag on my rewrite rule it would pass through the rewritten url:

I tried it, and it didn't work

After a little more time of frustrated googling, the most obvious thing finally occurred to me: I should try both of the above things together. That, of course worked. So I now I have mod_rewrite working with Apache & Tomcat via mod_jk. Additionally, I was able to restore my stricter rules on what gets passed off to Tomcat:

Update: I was asked to post my httpd.conf, so here it is (in sections):

Read more...