We at Varnish Software are all about speed. Our web accelerator, Varnish Cache, is built for speed. It executes its policy code more or less a thousand times faster than your typical Java or PHP based application servers, mostly due to the fact that the configuration is compiled into system call free machine code. System calls require expensive context switches, stall the CPU and wreck havoc in the CPU cache so avoiding them makes the code fly. There are strong limitations on what kind of logic you can move into Varnish Cache, but the logic that you do move there will run very fast.
Access control made speedy
An example of code you can move into Varnish is code for controlling access to your website content. In a traditional environment the caching layer only serves up pieces of content without giving any thought to who gets access to it. Since the rules governing access control can be rather complex these rules have traditionally been implemented in the application server, which is slow. And slow is a word we don’t like to hear. But with a bit of effort and some open source magic you can serve access controlled content from the caching edge layer.
How would it work?
Varnish Cache would need the following information:
1. A header coming from the origin server indicating that this piece of information is under access control, maybe X-Access-Control. If the header is present Varnish would then check whether the user is logged in or not, using a cookie.
2. This cookie would be set by an authentication service, and if you are worried about users cheating you could secure it by signing the cookie cryptographically. It’s possible, but not recommended to implement the actual authentication in Varnish itself using modules to access data in a database or another data source. As each user usually only logs in once this is is not a performance critical path and so it makes more sense to do it on your regular application servers.
3. If the cookie indicates that the content could be released to the user then Varnish will let it go. If not, Varnish would redirect the user to a page consisting of a preview of the article and a login box.
Setting up a POC
Getting a proof of concept up and running is fast. You could just check for the presence of a certain value in a cookie in vcl_deliver and you’ve proven the concept. The more advanced controls will require more effort, maybe a week or two of work, depending on the complexity.
When moving logic away from your application servers. You must always maintain clear guidelines on what goes where or you’ll quickly end up with a messy infrastructure. In some organization the edge cache is considered infrastructure and not part of the web application and handled by different teams.
- Digest VMOD, https://www.varnish-cache.org/vmod/digest
- Redis VMOD, https://www.varnish-cache.org/vmod/redis
- Writing VMODs, http://blog.zenika.com/index.php?post%2F2012%2F08%2F21%2FCreating-a-Varnish-module
- The Varnish Book, https://www.varnish-software.com/book
- The Official Varnish Documentation, https://www.varnish-cache.org/docs/
Hrafnhildur Smaradottir is International Marketing Manager at Varnish Software and is located in Oslo, Norway. Varnish Software is the world's leading provider of open source web application acceleration software and helps customers make their websites fly.