Now that we've seen how the access system works in Drupal 8 at a basic level and how we can define permissions and check user credentials, it's time to talk about routes.

As we saw from the very first time we wrote code in this book, routes are the entry points into your application. Also, as a developer, it is one of the main things you'll be dealing with, so controlling who can access these routes is the responsibility of the access system.

There are a number of ways we can ensure that routes are only accessible to the right users, so let's see what these are.

The simplest way is by checking for a permission. We actually did that in Chapter 2, Creating Your First Module, when we defined our hello_world.hello route:

hello_world.hello: 
  path: '/hello' 
  defaults: 
    _controller: 'Drupalhello_worldControllerHelloWorldController::helloWorld' 
    _title: 'Our first route' 
  requirements: 
    _permission: 'access content' 

The requirements key in a route definition contains all the data that the request trying to reach this route must have. This contains mostly access-like information but also things such as the request format.

The requirement in the previous example is _permission (all these options typically start with an underscore). It is used to specify that the user accessing this route needs to have that permission, similar to how we checked whether a user has it earlier:

$account->hasPermission($permission).   

The access content permission is something defined by Drupal core and is basically the one you'd use when the restrictions are very lax, meaning that all users should be able to access the resource. By default, this permission is also present on the Anonymous user role.

Speaking of lax restrictions, there is one option that is even more open, fully open:

_access: "TRUE"  

This essentially opens up the route to basically everybody under any circumstance—not something you'll probably use often, but it's handy in some cases.

Returning to permissions, we can also include multiple permissions in this requirement. For example, to check whether a user has either of two permissions, we separate them by a comma:

_permission: "my custom permission,administer site configuration"  

For checking whether the user has all the given permissions, we separate them by a plus (+) sign:

_permission: "my custom permission+my other permission"  

So, we can already see quite some flexibility.

Next, we also have a requirement by which we can check whether the user has a given role. In a similar manner, we can include multiple roles to check, depending on whether we want to do AND or OR checking:

_role: "administrator" 
_role: "editor,administrator" 
_role: "editor+administrator"  

This approach is not as flexible as using permissions and it's a little "hardcody". By this I mean that you are hardcoding an access rule based on site configuration (as roles are configuration entities). If that configuration is removed, you may have broken code. Permissions, on the other hand, are also code, as they are defined in a module (or Drupal core). However, the option is there if you need it.

The next type of requirement we should be covering here is _entity_access. However, understanding this requires us to first know a bit about entity-level access, so we will skip it now; we'll definitely come back to it later in the chapter. Instead, we will talk about the mother of all route access approaches—the custom one.