We love coffee.  It drives us.  It keeps us going through those long, grey days and those too-bright early mornings.  We also love Gimme! Coffee, our local roaster and snooty-delicious provider of the bean.

One of the many perks that comes with working here at AWP is free coffee.  And not just any coffee, we get free Gimme.

That is until we decided to experiment and try out another, Ithaca-based coffee roaster.  You know, for fun.

Well, we paid for that.  Our alternate, unnamed roaster’s coffee tasted like sweet dirt.  Or acid.  We couldn’t decide.  Maybe if a hobo decided to eat sun-baked dirt all day, and then we made him throw up after drinking too many shots of Green Apple Puckers, the resulting hot stew would be akin to what we had just purchased 10 pounds of.

Dammit.

Well, after courageously drinking as much of that swill as possible (with lots and lots of cream), we finally hit the new month, and could go back to our regular provider of coffee: our sweet, sweet Gimme.  Forgive us baby, please.  We didn’t know.

It all serves to illustrate an important point: never try anything new.

I’ve been wrangling with the Cake’s Security Component for the past day, not having the best time with it. If you’ve been trying to use it, you may have noticed that there seems to be near-total lack of documentation on it. Not cool.

So I was trying to use it to make some simple HTTP Authentication requests for a WebTree site of ours. It turns out that whenever the Security Component is initialized in a controller, it requires that all POST-ed data in that controller be validated through the Security Component. For this to work correctly, and not spit you out into a blank page “black hole,” you have to use the Form Helper for every form that needs to be submitted, making sure to use $form->end().

It looks like the Form Helper builds a Hash number based on the name of the fields included in the form and the Security Salt that you set in the config/core.php.

When the form is submitted, a function, __validatePost(), runs automatically, there is currently no way to turn it off, and tries to make the same hash value as all the fields present in the Controller’s $data variable. If the two hash values are the same, we know that no extra data is being submitted directly to the controller, and we proceed with the normal course of things. If they don’t match, we trigger the Black Hole callback function, and go down that route.

Except that in the current RC2 release (7296), there is a bug in the Security Component that will ensure that these two hashes will never be equal.

The problem is in line 662 of /cake/libs/controller/components/security.php:

$check = md5(urlencode(Security::hash(serialize($field) . Configure::read('Security.salt'))));

Should be:

$check = urlencode(Security::hash(serialize($field) . Configure::read('Security.salt')));

Take out the md5() function. Form Helper’s security function that generates the form’s hash value does not include the extra md5 hashing function. It looks like this was fixed in the nightly build.

This will alleviate some of your potential issues using the Security Component. However, if you just want to use some aspects of the component, such as HTTP Auth, there is no way to disable the POST validation, much to my chagrin. Maybe it will change in the future.

Ahh, yes. The shared pain/annoyance of upgrading Cake from RC1 to RC2 and finding that the SQL operator syntax has changed.  Sure it’s more sequre, sure it’s not as elegant looking, and sure there seems to be zero backward compatibility, but yeah, it happens.  It’s still a pre-release.  We deal.

So for those that currently use iano Iglesias’ super-helpful Sluggable Behavior, make sure to change line 121 from:

$conditions = array($Model->alias . '.' . $this->__settings[$Model->alias]['slug'] =>' LIKE ' . $slug . '%');

to:

$conditions = array($Model->alias . '.' . $this->__settings[$Model->alias]['slug'] . ' LIKE '=> $slug . '%');

The current version, 1.1.36, does not include this fix for Cake RC2. Without this, you’ll start getting duplicate slug values, lacking any numerical appending action.

Today, in development, I noticed that a drop down menu I was building had inconsistent line-heights between Firefox 2 and the new Firefox 3. Using Verdana, font-size:10px, Firefox 3 rendered the height of the line as 14px tall, whereas Firefox 2 was only 12px. Because of the inconsistent height, I couldn’t line my drop-down menu up correctly in both browsers.

An excellent way to see this inconsistency in action is through Eric Meyer’s Javascript line-height test. Just open up this link in different browsers and the rendered line-height will be displayed for you.

Although we are used to making special considerations for Internet Explorer and Safari, problems between releases of similar browsers are much harder to solve for. It took me awhile to figure out what the problem actually was.

The solution, luckily, is quite simple. Set

body {line-height:1.5}

(or some other unitless value)

You will want to put this at the top of your reset.css stylesheet which you should be using for the greatest browser consistency possible. Here at AWP we like to use Blueprint CSS Framework which uses reset methods developed by Eric Meyer’s.

Now my drop-down menus line up correctly! Yes!

Casey makes sure it is straight and stuff.

This post might already be a little outdated, but somehow in the transition to our new everything, one of the coolest pieces was left unmentioned: our super-awesome huge hall sign!

Swing by the office and check it out. It’ll make you smile. It makes us smile.