arch bash cakephp conf dauth devops drupal foss git golang information age life linux lua mail monitoring music mysql n900 netlog openstack perf photos php productivity python thesis travel uzbl vimeo web2.0
In the Cake community, there has always been much interest in authentication/authorization systems. The issue of authentication has been addressed in several add-ons provided by the community, such as DAuth (written by me), OthAuth (written by Crazylegs) and many others.
However, one of the additions to the 1.2 branch which is currently in active development , is a built-in auth module. A module that isn't finished yet but it sure is worth it looking at. (In fact I'm thinking about making a new dAuth version built on cake's own auth system.). As most bakers know, there is very little information about the 1.2 branch in general, and the auth component in specific. So what I will try to do, is delve in the code, mess with it, and explain my findings in this post. For this first post it will be more trying to decipher the source code, messing with it will probably for a little later on.
Disclaimer: not everything I'll say here will be correct, first of all because I'm not able to fully understand every piece of the source code (yet), secondly because the 1.2 api is still changing.
The version i use for this post is svn head. (revision 4758 at time of writing)
So let's just open cake/libs/controller/components/auth.php.
Reading the first comment we immediately see "Manages user logins and permissions." This looks very important to me. Seems like this component handles both authentication and access control. It seems like the AuthComponent is able to interact with the ACL system that we know from the 1.1 branch. Multiple uses of the AclComponent ($this->Acl inside the component) confirm this.
The AuthComponent has quite some member variables, the most important ones seem to me:
Now, let's move on to the available functions (the most important ones that is) ...
This was only a slight introduction, more research (and thus explanations) will happen later on and you can also expect some sample code. Give me some time though ;-)
Hi, just stopped by to write "Thank you for your effort" and awaiting further research and ultimately the new dAuth:)
Posted by Tarique Sani on Sat Apr 7 23:17:39 2007
Hey Dieter, thanks for breaking this down. Do you think the API is set and the functionality is solid enoguh to use? I would love to use it, but if they are just going to change the interface on me in a month then I don't want to use it.
Posted by rtconner on Mon Apr 9 17:01:34 2007
@Tarique: you're welcome :-)
@rtconner, that's always a guess... Even the cake team itself can't be sure how it will evolve, although off course they'll have a better view on it then us, so I'll ask the guys if they want to read our questions and reply to them.
When I think about authentication, I find features like these a must: challenge response (passwords being sent over a network, hashed according to al algorithm that changes all the time), a configurable fall back , brute force (hammering) detection and blocking, user configurable hashing (some want md5 (although md5 is weak), others like sha1, or others, or combinations of them), session hijacking protection (cake already does quite a bit in that area, but imho afaik not everything required for a secure auth system, you'll find more about that in the DAuth article),...
So, those features are the one I implemented in DAuth. Probably I mix auth-system specific aspects with application-specific ones. I have learned a lot by checking code from the cake team and often thinking "hey this is a better approach to structure this functionality". Also, some of the stuff DAuth has, becomes obsolete when https (SSL) is available. On the other hand, on my DAuth todo list are features that are behavior you would get by using https, but I want to offer them to those who have no https available, and want to be secure.
So, 2 things i wonder: (just like you)
1) how drastically will the API change? (not too much I think but you never know)
2) which features from my list will be implemented, and especially where? And also, how (and especially where) do we write our own logic if we want certain features that aren't available in cake's AuthComponent. Would this even be good practice? I think yes because I think features like the ones mentioned above are critical for security, but I can imagine the cake guys don't agree with the way DAuth (and other systems) are built and have much advice for us in that area.
Posted by Dieter_be on Tue Apr 10 06:36:51 2007
Thank you very much!
Posted by snbzcy on Fri Apr 20 10:35:38 2007
you're welcome \o/
Posted by Dieter_be on Tue Jun 12 07:16:24 2007
Hey Dieter !!
As I've been way to much involved in my new job here in the UK I haven't had any time to catch up on the new features in 1.2.
First it's quite refreshing that this is getting into the core !!!
Second, many thanks for the breakdown since I'm gonna start a project based on 1.2 and was wondering if all my investigation around ACL and AUTH was to 1.1 centric and would have to recode the whole bunch of examples I've collected.
Second I would like to leave the link to some code someone posted on the ML:
Auth component + Cake 1.2
Gustavo Carreno aka [Batch]
Posted by Gustavo Carreno on Thu Jun 21 19:41:13 2007
auth has to change in the startup fun.
i found the block if(this->authorize) has to change to
for things to work fine
Posted by Anonymous on Tue Sep 18 03:28:05 2007
this will disable the acl from being checked.
Posted by the Anonymous on Thu Sep 20 01:51:22 2007