Tag: Kohana

Cache Control With Kohana 3

January 11, 2012 » Geek

I recently did some work with cache control in Kohana and found the documentation a little thin out there, so I thought I would share what I learned.

Kohana has nice built in functionality for ETag validations, so you don’t really need to roll your own cache headers.

If you need to brush up on web caching in general, I would recommend a quick read of Caching Tutorial for Web Authors and Webmasters, an excellent and concise reference.


For the purposes of this example, I’m creating a small controller which will use a short string as it’s response body. The implementation here is trivial.

Let’s look at the headers that are returned by default. Your headers may vary, so adjust accordingly.

If you look at the response headers from this request, you will note that there no Cache-Control, Last-Modified or ETag headers are returned. That gives us a blank slate to work with.


An ETag is a unique identifier string describing your content for cache validation. ETags have an advantage over Last-Modified headers in that there is no need to worry about clock synchronization. The server can determine how to generate ETags in any manner it desires.

The Response object in Kohana provides two methods useful for ETag based caching. The first is Response::generate_etag(), the second is Response::check_cache().


This method uses the sha1 hash to create a unique ETag based on the content of the rendered response. Because it renders and hashes the response before returning a result, there is a memory and CPU time hit, which increases with the size of your response.


This method is the one we will use directly, as it compares the ETag of the response to request headers and takes the appropriate action.

It’s signature is ($etag = NULL, Request $request = NULL). This is a bit odd, because although both are NULL by default, and the Request parameter is second, it is not optional while $etag is.

If you provide NULL for $etag the method will use Response::generate_etag() to get a valid ETag. As mentioned above, this is not always the optimal choice, so if you have a unique identifier that you can provide, you should.

Since this is a simplistic example, I will let Response::generate_etag() create my ETag value.

Let’s see the response headers for this version. We now have an ETag header, at the very bottom.

If we refresh the page again, we see that the browser sends an “If-None-Match” request header, which Response::check_cache() compares to the ETag. Finding that they match, the method returns a 304 response and immediately exits the script, causing the browser to use the cached version and saving the time it would take to send those bytes.

To demonstate how the ETag is generated let’s modify our response body so that it returns new content for every request (well, every second at least).

After refreshing we get a new body, and a new ETag, breaking the cache and re-sending the entire page.

Remember, if you implement this, you should try to use an alternate ETag value if you can.

Cache Control

ETags aren’t useful without a Cache-Control header, but you can set that yourself with Response::headers(), just be aware that Response::check_cache() will append must-revalidate to your header value, so don’t add that part yourself.

Hopefully that clears up how to use the built in browser cache handling in Kohana 3, please leave your own tips or experiences in the comments!

Replacing Kohana 3 Auth module hashing

November 9, 2011 » Geek

The password hashing in the Auth module provided with Kohana 3.1 is not very good. By default it is a simple sha256 hmac with a global salt.


This isn’t strong. If you loose the hashes and the salt it’s just a matter of winding up a GPU.

So how can we fix this? Well, thanks to Kohana’s structure we can easily override the Auth class and tweak it. However, due to Auth’s structure, we can’t drop the global salt. The hash function has to stand alone, so no passing in salts from the database.

That leaves us with key stretching.

Now, I don’t want to deal with a custom key stretching implementation, I’m not a cryptographer. So, let’s find an existing algorithm.

One that pops to mind is PBKDF2. This is a pretty simple algorithm, so it was easy to find and spot check a PHP implementation

We just take some test vectors from RFC 3962 and run them against the code we found.

Run it, and everything checks out:

So now all that’s left is to drop it in, which is pretty simple. One thing to note is that I wanted this to stay compatible with the default auth config file, so I just extended that a little bit.



One item to note is that I am packing these with base64_encode. This is to fit into the default field type for the ORM driver. That is also why my length is stunted to 45. If you really want to go all out, alter your table to use a TINYBLOB, up the length to 256 bit and up the rounds.

So that is how I replace weak hashing in K3 with something a bit better.

How do you do it?

Kohana 3 OAuth & Twitter Demo Code

October 6, 2011 » Geek

The Internet seems a bit sparse when looking for good demo code for using the Kohana 3 OAuth module with Twitter.

I think the main issue is that the OAuth module isn’t very well documented, and doesn’t do API requests. For that you need an API implementation, like shadowhand/apis.

Anyway, here is a gist I put together with an example controller for Twitter OAuth:


Clean Auth module usage in Kohana

February 24, 2010 » Geek

I’ve been learning the Kohana framework for a project at work, and I have to say I really like it. It has a lot of the things I liked about rails, and it stays out of my way, unlike CakePHP.

I thought I’d highlight my authentication solution that uses the built in Auth module and a base controller that I call Site_Controller. Keep in mind that all of my controllers derive from this one.

So, what’s it boil down to? Essentially you set up Auth and my base controller, then in your children controllers you can set $access_control to an array of methods you want protected. It works with key == method and value == access level. For values you can have “*” which means anyone logged in can use the method, or a string providing a specific role. Take a look at the controller then I’ll show you an example usage.


Here’s an example controller. In this case anyone can access login, anyone logged in can access index and only logged in admins can access adminsonly.


I haven’t done a ton of testing and it’s not the most robust solution, but I like it and it was easy to write.