On the Happyr.com Developer blog Tobias Nyholm has written up a tutorial showing how you can use functionality included in the Symfony framework to define access control rules in a database using voters and values stored in the database.

I was recently at a PHP conference in Odessa where I met many great developers. One of them asked me a question, that the answer was not obvious. His use case was that he wanted to use Symfony's Access Control configuration to restrict access in his application. But he also wanted to configure the rules dynamically.

Since all the configuration in Symfony is cached with the container for performance reasons, we could obviously not allow a use a database to somehow “print” new configuration. We need to do something smarter.

Voters are a part of the Symfony security component and are set up as a service in the Symfony DI container. When a route is defined in the access_control section, the matching voter is called and the access granted/denied state is determined by values from the token and subject provided (from the database).

On the Laravel News site there's a post detailing some of the updates made to session and controller handling in v5.3 of the framework. It mostly revolves around how the middleware handling changed on each request from v5.2.

Back in laravel 5.2, a developer was able to interact with the session directly in a controller constructor. However, this has changed in laravel 5.3.

The difference between how the 5.3 & 5.2 handle an incoming request is that in 5.2 the request goes through 3 pipelines: global, route and controller [...] In 5.3 the request goes through only 2 Pipelines: global and route/controller (in one pipeline).

The post includes a quote from Taylor Otwell (creator and lead developer of the framework) about why this change was made. Then it shows an alternative to directly accessing this session information in your controllers: a Closure-based middleware in the constructor to execute your checks.

On the Codevate.com blog there's a tutorial posted by Chris Lush showing you how to secure your client-side public API with OAuth 2 (based on the Symfony platform).

Say you’ll be developing a web application for a customer to create and manage restaurant bookings, exposing restaurant information (name, opening times, menu contents etc.) and booking creation as RESTful API endpoints, which are consumed by secure admin backend. You’ll need to authorise access to the API, but there is no end-user involved since the web app is its own resource owner, so the previous flow doesn’t apply.

[...] However, you also need to develop a booking widget that will be embedded in a company or restaurant’s website for visitors to use. In this case, the client-side is no longer trusted enough to share the OAuth client secret that’s required to authenticate with your API. [...] We encountered a similar use-case for a client project recently, and this blog post details the steps taken to address it.

He then shows how to integrate the FOSOAuthServerBundle bundle into your current Symfony-based application and the updates you'll need to make to your security.yml file. He includes the code needed to create a "client" and associating it with a company already in the customer list. Next is the creation of access tokens and linking them to the restaurants in their system (a unique identifier to use externally for the restaurant rather than an ID). He shows an example of handling the token requests and the code/config changes needed to set it up. Finally he talks about scoping API requests down to certain functionality and an example cURL call to the API to show the results of it all combined.

On the PHPDelusions.com site there's a post that compares the functionality of mysqli to PDO and looks at the differences in their overall usability.

By no means I am going to say that mysqli is worse than PDO. Mysqli is an excellent extension, with many specific features. But it's just not intended to be used directly. To make it usable, one have to always wrap it into a helper library, to reduce the enormous amount of code that otherwise have to be written by hand.

[...] But for the average PHP/MySQL user, standard APIs are the only known methods for database interaction. Thus they tend to use both extensions right in the application code, without any intermediate wrapper around. For such a use PDO is an indisputable winner, and I'll show you why.

The post then breaks it down into sections comparing the functionality between the two database access methods:

• Named placeholders
• General inconvenience in binding
• Getting single column value
• Getting multiple rows
• Binding unknown number of parameters
• Compatibility

Of course, all the inconveniences above could be overcame by a good wrapper. This is why if you choose mysqli, you definitely have to use one.

Lorna Mitchell has a post to her site with some helpful instructions for the CakePHP3 users out there around access control. The framework comes with no built-in functionality for authentication so she shows how to set up your own.

The newest version of CakePHP doesn't ship with built in ACL, which means you need to write your own. Personally I think this is a smart move, having looked at the one-size-fits-all solutions for previous versions of the framework and knowing that every system has different requirements, this version has good hooks and documentation on how to add something that works for your application. I thought I'd share what worked for mine.

She starts with some of the initial setup: creating the relationship between the users and her custom roles table and "baking" the controllers and templates. She then goes through the use of the authorize method and how it can handle the user/request combination to determine access. She includes the code for her auth class, showing both the authorize method and a simplified userHasRole method. She walks you through the code and one downfall the setup has: not being able to validate access in views and templates.

The SitePoint PHP blog has posted a tutorial from Bruno Skvorc showing you how to use Rauth, a tool that's designed to control access to parts of your application as set by annotations in the code.

Rauth is SitePoint’s access control package for either granting or restricting access to certain classes or methods, mainly by means of annotations.

[...] Traditional access control layers (ACLs) only control routes – you set anything starting with /admin to be only accessible by admins, and so on. This is fine for most cases, but not when: you want to control access on the command line (no routes there) or you want your access layer unchanged even if you change the routes Rauth was developed to address this need. Naturally, it’ll also work really well alongside any other kind of ACL if its features are insufficient.

He starts by dispelling the common thought (at least in most of the PHP community) that annotations are a bad thing and relying on them for functionality isn't a good practice to follow. With that out of the way, he shows a simple example: a set of users and fake routes that are evaluated by Rauth based on the annotations in a One controller-ish class. He describes what the evaluation is doing and how changing the annotations would make a difference in the results. He also includes a dependency injection example with PHP-DI and the Fast-Route package and a more "real world". He ends the post with a look at another handy feature of the library: bans (blocking based on other types of annotations, @auth-ban).

Gonazalo Ayuso has shared a method he's found for injecting providers into Silex that replaces accessing the dependency injection container as an array. It instead replaces it and allows defining function parameters instead.

I normally use Silex when I need to build one Backend. It’s simple and straightforward to build one API endpoint using this micro framework. But there’s something that I don’t like it: The “array access” way to access to the dependency injection container. I need to remember what kind of object provides my service provider and also my IDE doesn’t help me with autocompletion. OK I can use PHPDoc comments or even create one class that inherits from SilexApplication and use Traits. Normally I’m lazy to do it. Because of that I’ve create this simple service provider to help me to do what I’m looking for. Let me explain it a little bit.

He includes examples of both the normal way you can access Silex's injection containers (the "array access" method) and contrasts this with his updated method, via a method parameter on the route closure. His service provider (complete code in the post and on github), when registered, looks for controller events and performs reflection on the closure to detect which objects need to be injected. The method is then called normally but with the extra attributes set, populating the parameters.

On the SitePoint PHP blog they have a post that "reintroduces PDO" or as they describe it, the "right way to access databases in PHP". The PDO functionality in PHP provides extra handling around database connections and queries as well as making it easier to connect to multiple types of databases with similar code.

PDO is the acronym of PHP Data Objects. As the name implies, this extension gives you the ability to interact with your database through objects. [...] PHP is rapidly growing, and it is moving toward becoming a better programming language. Usually, when this happens in a dynamic language, the language increases its strictness in order to allow programmers to write enterprise applications with peace of mind.

In case of PHP, better PHP means object-oriented PHP. This means the more you get to use objects, the better you can test your code, write reusable components, and, usually, increase your salary. Using PDO is the first step in making the database layer of your application object-oriented and reusable.

He starts by answering the question most ask about PDO versus mysql/mysqli by pointing out that PDO is more OOP friendly, it allows for parameter binding and the fact that the mysql extension is no longer supported. He shows how to check and ensure PDO is installed on your setup and, if not, how to add it in (for both linux and Windows systems). The tutorial then walks you through using PDO: making the connections to the server, running queries and returning the results. This includes a section on prepared statements and bound parameters and their benefits including SQL injection prevention.

Rob Allen has a new post to his site today showing you how to access services in a Slim 3 application using container injection instead of the previous "getInstance" method.

One of the changes between Slim Framework 2 and 3 is that the application singleton has gone. [...] In general, you didn't need access to $app itself, but rather you wanted access to something that the app knows about, such as a database adapter, or the router for access to the urlFor method to create a URL to a route. With Slim 3, there is no getInstance() on App, so you need to inject the instances of whatever you need where ever you need them.

He shows you how to create a simple Slim dependency injection container (service locator?) and push two kinds of objects in for later reuse. He shows how to reference this container from inside of your routes in both the callable/closure and class contexts. He also includes an example of referencing the same container from inside middleware (again in both the closure and class contexts).

Joshua Thijssen has a new post today with a "neat trick" that the Symfony Security component allows - switching (impersonating) another user programatically.

This allows you to login as another user, without supplying their password. Suppose a client of your application has a problem at a certain page which you want to investigate. Sometimes this is not possible under your own account, as you don’t have the same data as the user, so the issue might not even occur in your account. Instead of asking the password from the user itself, which is cumbersome, and not a very safe thing to begin with, you can use the switch-user feature.

He talks about how to enable it, how to use it to switch to another user and, most important, how to restrict its use. He points out that there's no way to define who a user can switch to built-in, so he's come up with a custom "switch listener" to help add in this protection. His "SwitchUserListener" class replicates some of the code in the original handling (well, the whole class) and updates the "attemptSwitchUser" method to check the user they're trying to switch to and see if they have the right role. Finally he shows how to add it to the services configuration and how it overrides the default listener.