Zend Auth, if you want to secure a Zend Framework app, along with Zend Acl, it’s essential. But do you know what it is? Do you know how to use it? Do you know how to extend it? Through this series I’m going to show you how to do all three.
Zend Auth, if you want to secure a Zend Framework app, along with Zend Acl, it’s essential. But do you know what it is? Do you know how to use it? Do you know how to extend it? Through this series I’m going to show you how to do all three.
One of the reasons that I’m such a fan of the Zend Framework over many others, whether Kohana, Symfony, Prado or Yii or one of the other exceptional frameworks, is because of the dead-simple extendability of the core libraries.
Zend Framework – So Extendable
You can accept and use the core Zend Framework libraries as they are and you’ll get along just fine; but from time to time, you are inevitably going to run up against circumstances where you need more, different, custom or quirky, once-off functionality.
Whether you want to authenticate against Amazon S3 or Twitter, retrieve data from Redis, or interact with ZeroMQ, Zend provides a really simple path to extensibility.
So, for me, despite the oft derided performance issues associated with the Zend Framework, it’s design makes it very customisable and extendable in a clear, systematic and logical way. And for me, that more than makes up for other considerations. This is primarily because I like things neat, tidy and ordered and for me, it provides that in abundance.
So on Tuesday, the 21st June, I’m beginning a series looking at different ways in which Zend Framework can be extended and configured to take on different circumstances of authentication.
Zend Auth
In the series I’m going to look at the Zend_Auth classes, specifically how to extend them and in the process take you from beginner to pro (well, sorta). I’m going to start off by covering the basics of the classes and its approach to application authentication.
Then I’ll show you how to extend it and create a set of different adapters in addition to the existing 5 (Database, Digest, HTTP, LDAP and OpenID).
Part 1 - A Testing/Mock Adapter
The first is going to be a test adapter that accepts a default username and password, which are hard-coded as class constants. Now I hear what you’re saying – that’s wrong; but imagine a test situation where you are not connecting to a database, an LDAP directory, a configuration file, or a HTTP server – you want to mock the situation out.
All you want to know is that you can make the call and move on. In this situation this type of adapter would be ideal for your needs as you want to test functionality around it. So we’re not going to get too caught up in semantic issues, but use it to cover the basics of extending Zend Auth.
Part 2 - A Zend Config Adapter
Then, in part 2, we’re going to get a bit more advanced and extend the classes to create a Zend_Config-based authentication class. Whether you’re a fan of INI, XMLl, YAML or JSON, you can use any or all of them by the end of the second post to store user details (not that you likely would) to authenticate your users against. This kind of adapter would be great for simple purposes, smaller company intranets or small business purposes. Not a great use of security however.
Part 3 - A NoSQL Adapter with MongoDB
Finally, in part 3, we’re going to take it further and use MongoDB to authenticate against. Yep, unless you have your head underneath a rock these days you’ve heard of NoSQL and along with that, MongoDB.
Given that rapid growth in acceptance and popularity, it’s only right that we consider that too. But whilst we’re on the point, have you ever considered using NoSQL databases as a backend to your authentication work? Have you ever thought of using Cassandra, Redis, Hbase or Membase?
If not, maybe you should. You get features covering versioning, automatic caching, sharding and replication, depending on the database implementation you choose. They’re something to really behold – and they’re still early in their developing years. If you’re considering them, stick around for this one – it’s sure to whet your appetite for more.
So in the last installment of this series, I provided an introduction to Zend_Auth, Zend_Auth_Adapter_Interface and Zend_Auth_Result and how to implement Zend_Auth_Adapter_Interface to implement a basic test adapter that can be used as a mock object in your testing.
If you missed it, check it out now, then come back and we’ll continue on. If you’ve already read it, then let’s continue now.
As I indicated last time, whilst being a perfectly valid implementation, the Test adapter was rather basic and didn’t do very much. Like all good testing, you need flexibility and options. So in this installment, we’re going to build an adapter based around Zend_Config. This will lead quite nicely in to the last part in the series which uses the wonderful MongoDB as the underlying resource for the adapter.
The Zend Framework Bootstrap can be one of the key aspects of getting up and running quickly with the Zend Framework. Let’s make it easy.
Recently I was asked how to rename a file with the Zend Framework that used a Zend Form and Zend File element. They key requirement was that it should not be a hack or a kludged solution. So I thought I’d write a quick post to provide a simple example on how it was achieved.
Ok, we’ve established that with the Zend Framework, we need to do a bit more work than some of the other frameworks to get up to speed - but that’s not necessarily a bad thing - right?! But it can be a bit tedious and it’s something as professional developers, we want to automate away. So we’ve been addressing in this series how to do just that with a custom, extendable bootstrap class.
In the first part of the series we laid the foundation of our custom bootstrap class by creating a custom class directory structure, adding its namespace to the application ini and modifying the default application bootstrap so that it extends from it and had a look at the first component - caching.
Then, in the second part of the series, we built on the foundation laid in part one by creating plugin resources for the routing table, application navigation and the database connections - these being some of the most common tasks, usually, associated with a web-based application.
In this, the third and final part of the series, I’m going to finish up by looking at application placeholders and surprise, no not logging as originally promised, but pagination. As an added extra, we’re going to be using a key feature of Zend Application to make it a breeze.
Join the discussion
comments powered by Disqus