So, what are the advantages of an ACL model? The first advantage is security. Using this model will make your application more secure and less vulnerable to exploits. When securing any program, it is good to give to the user only the privileges he/she needs. That means that, for example, you should not give super administrator privileges to someone who will only manage website content. The ACL security model allows you to do just that. The second advantage is the easiness of user management. You can divide users into groups, while each group has certain access permissions. Also, you can easily add new user groups, delete the old ones or change group permissions.

They include the database structure you'll need to make the backend work (four tables) and the code to create an "Acl" class with methods to check a user+group for a permission, get the permissions for a user and get the permissions for a group. It's a pretty simple system and has a lot more that could be added to it to make it more robust, but it's a good start.

Wouldn't it have been better for them to able to maintain their database where ever they were? Of course, but how? Simple - put it online. [...] In this article I'll focus on the essential elements of PHP you'll need to use an existing Access database online. One other item that's standard with a Windows installation is the availability of ODBC drivers. These are essential for the use of Access from PHP.

He includes a sample database structure (with "product", "product_category" and "category" tables) and includes some sample code showing how to connect to the remote database and perform some basic actions - select, update, insert and delete

In this article I will discuss my personal favorite approach: role based access control (RBAC). RBAC is a model in which roles are created for various job functions, and permissions to perform certain operations are then tied to roles. A user can be assigned one or multiple roles which restricts their system access to the permissions for which they have been authorized.

He starts with a warning that, if not properly maintained, a role-based system like this can get to be somewhat chaotic so a rules should be in place around the adding and removing of permissions at certain times. His functionality is based on a few database tables - roles, permissions and cross-reference tables between users/roles & permissions/roles. All of the code you'll need to implement the system is included in a Role class, the PrivilegedUser class and the methods you'll need to add/remove/check the logged in user's permissions.

Continuing with Access Control Lists, we will read about the two Access Control Lists and their mapping. The Access Request Objects (AROs) are a list of the things that seek permissions and the Access Control Objects (ACOs) are the resources on which permissions are required. Both the lists are maintained in the tow tables, namely aros and acos respectively.

Included in the post is the SQL you'll need to create the tables for the system to use as well as some basic code to use the AclComponent with the ACOs/AROs. They also show how to use the parentNode method to create parent/child relationships between the objects.

I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. [...] This entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.

In this latest post, she talks about the three different types of tokens - consumer, request and verififier - and how to use them to locate a user in your app's users. Her code validates the request token and verifier against the database and, if successful, inserts the rest of the token information for the user.

Of the other patterns mentioned, the one closest to the Proxy is the Decorator. In the case of a Decorator, the focus is on adding functionality to an existing object -- for instance, adding methods, processing input before delegating to the target object, or filtering the return of a method from a target object.

Proxies stand in for objects and have several benefits for your application that may or may not need all of the overhead a full object could cause. Matthew focuses on one benefit in particular - consuming and controlling access to another object. He sets up a problem of wanting to use properties/methods on objects that aren't exposed directly (like a protected method). His solution is a proxy layer class on top of the original object. He includes a few "gotchas" to look out for when using this technique including overwriting all necessary methods and copying over all of the needed properties.

PHP Data Objects, or "PDO" as it is commonly known, is a lightweight database abstraction layer that is arguably the best, at least in terms of speed. A great deal of this speed is owing to the fact that the PDO extension was compiled with C/C++. The extension became available in PHP5, and as with any other database abstraction layer, its aim is to provide a uniform interface to access a variety of databases. This is also a way for developers to create portable code for a variety of platforms.

The tutorial shows you how to find the enabled PDO connection types for your installation (and where to go if you have access to turn more on or off). They show an example connection - in this case, to a MySQL database - and how to run a query or two using this new resource.

After what felt like years of debate over the notation to use for PHP's namespaces, it seems like the feature itself has had relatively little use or attention since it was actually implemented in PHP 5.3. We're all used to working without it but using it does make code neater.

Her three options are:

• Refer Namespace and Class Name
• Import the Namespace
• Alias the Namespace and/or Class

You can find out more about namespaces in PHP applications on the PHP manual.

Developers who are familiar with the topic of clean code know that static methods are a problem, especially if it comes to testability. Static makes the code global, and if there is some kind of state involved it is even more a problem because this is global state then - both a maintenance and testability nightmare. [...] How can we keep our code clean and testable, at best without having a strongly coupled dependency to the class hosting the static method? Enter dependency injection for static methods.

He gives an example of how to use this to create a simple class that can change the name of the object an inner static function call is made to.

I've been looking into OAuth recently and really like what I see, so I started looking at actually starting to play with something that uses it (and isn't twitter). In the pursuit of this, I spent some time walking through the process of how to actually authenticate using OAuth, as a client.

She briefly touches on the consumer key and secret and how those are passed along with the OAuth object creation to grab a request token, complete with details on setting a callback. She also mentions how to grab an access token - a piece of information you include in your API calls to let the remote service know who you are. All of her examples are using Yahoo! OAuth services.