Using Yii’s Inherent Security
By perusing the blog demo that ships with a standard Yii 1.1 install, one will see that the authentication system takes those best practices a step further. To extend our fortress analogy a bit further, the Yii blog demo has a portcullis, a moat, and alligators in the moat. The system uses an sqlite database and an md5 hash to authenticate against.
We are going to, first, use the authentication system as it is set up in the Yii blog demo, with several additions to have it do as we need and want. The blog demo uses a sqlite database. I used a mySQL in my implementation of this. It shouldn’t matter what kind of SQL database you want to use (lite, my, postgre, or msSQL) . You should make whatever kind of corrections (or not) to your config files. As said before, there is enough in beginner tutorials and other documentation in setting up your db of choice.
What you need:
1) Web server capable of running Yii 1.1+
2) Yii framework installed
3) Ability to create a simple web app with Yii
4) A database that mimics the ‘tbl_user’ database in the blog demo
tbl_user has a column for ‘salt’, which we will ignore (and is part of our pared-down authentication). This is an additional hash which should be created at the time the account is created and is used like a secret password callback used by many APIs and data interfaces for enterprise-grade applications.
For our purposes here in a developmental environment I have opted to disable, with an option to reinitiate that process when so desired. The reason I have done this is that the authentication system is going to have a social login API functionality added to it later, so I want to leave the authentication system as simple as possible for that API use later on.
The authentication system we want to build will be used for a site that has a tiered-subscription system. In this example, we had three subscription types. For security reasons, my preference is not to have an admin-level authentication enter through this gateway. I have decided that building an admin module, which allows for only admin actions to be performed on the database, which will have all the authentication in layers we can muster and still leave the admin role/module with enough flexibility to do what we need. This will not be built or discussed here. I only make a note that our authentication system for our subscribers has a pared down security protocol, as compared to one that uses a ‘salted’ system.
What I did – you may have done it a bit different, which should be fine for this flexible example – was to create a new folder on my localhost, copy the files in the blog folder from yii/demos/blog/ into my newly created folder at the localhost, and then update the index.php file in my new blog to route correctly to the yii framework installed on my localhost.
The update you will also have to make to this file, if you are following this example closely, is simply change the path/to/yii/framework/yii.php to reflect where your new blog is located on your server. In my case I created a MySQL database called ‘blog’ and a ‘tbl_user’ table with one account, demo/demo. Then, updated the main.php page to reflect those data source changes I made, and by default the blog uses an SQLite database. Then, I ensure that my new blog authentication system is working for the demo/demo account.
Next, I updated the config/main.php files to make the Gii available. This step is not necessary. You may use the command line if you prefer here. Then, I made a user controller with all the CRUD functionality. Because this is a subscription-based account system, I opted to change the access rules to all the CRUD components, except the ‘create’ action. We need new users to be able to only have access to account creation. Once the account is created and they’ve authenticated in, we can allow them access to the other possible actions they can perform on their account.
To build this functionality, go to your newly-created user controller and update the accessRules method in the controller.
public function accessRules()
{
return array(
array(‘allow’, // allow all anonymous users to perform ‘create’ actions ONLY
‘actions’=>array(‘create’),
‘users’=>array(‘?’),
),
array(‘allow’, // allow authenticated user to perform ‘index’,'view’,'update’,'admin’,'delete’ actions
‘actions’=>array(‘index’,'view’,'update’ ,’delete’,’admin’),
‘users’=>array(‘@’),
),
array(‘deny’, // deny all anonymous users to perform ‘index’,'view’,'update’,'admin’,'delete’ actions
‘actions’=>array(‘index’,'view’,'update’ ,’delete’,'admin’),
‘users’=>array(‘?’),
),
array(‘deny’, // deny authenticated user to perform ‘create’ actions ONLY
‘actions’=>array(‘create’),
‘users’=>array(‘@’),
),
);
}
I then tested it with the demo account, logging in and logging out to make sure that only non-authenticated users could access the create activeRecord and authenticated users could access all the actions but the create action. Ideally, we wouldn’t want our users to have access to the admin controller, but in the development environment we keep it simple, leaving room in our code to scale our code out for necessary functionality later.
That’s it! We should be able to login and logout of the system using or demo/demo account.
