Added architectural decision record for the API key roles

CONTRIBUTING.md

@@ -46,27 +46,28 @@ This is a simplified version of the project structure:
 ```
 shlink
 ├── bin
-│   ├── cli
-│   ├── install
-│   └── update
+│   ├── cli
+│   ├── install
+│   └── update
 ├── config
-│   ├── autoload
-│   ├── params
-│   ├── config.php
-│   └── container.php
+│   ├── autoload
+│   ├── params
+│   ├── config.php
+│   └── container.php
 ├── data
-│   ├── cache
-│   ├── locks
-│   ├── log
-│   ├── migrations
-│   └── proxies
+│   ├── cache
+│   ├── locks
+│   ├── log
+│   ├── migrations
+│   └── proxies
 ├── docs
-│   ├── async-api
-│   └── swagger
+│   ├── adr
+│   ├── async-api
+│   └── swagger
 ├── module
-│   ├── CLI
-│   ├── Core
-│   └── Rest
+│   ├── CLI
+│   ├── Core
+│   └── Rest
 ├── public
 ├── composer.json
 └── README.md
@@ -77,7 +78,7 @@ The purposes of every folder are:
 * `bin`: It contains the CLI tools. The `cli` one is the main entry point to run shlink from the command line, while `install` and `update` are helper tools used to install and update shlink when not using the docker image.
 * `config`: Contains application-wide configurations, which are later merged with the ones provided by every module.
 * `data`: Common runtime-generated git-ignored assets, like logs, caches, etc.
-* `docs`: Any project documentation is stored here, like API spec definitions.
+* `docs`: Any project documentation is stored here, like API spec definitions or architectural decision records.
 * `module`: Contains a subfolder for every module in the project. Modules contain the source code, tests and configurations for every context in the project.
 * `public`: Few assets (like `favicon.ico` or `robots.txt`) and the web entry point are stored here. This web entry point is not used when serving the app with swoole.
 
@@ -134,3 +135,9 @@ In order to provide pull requests to this project, you should always start by cr
 The base branch should always be `develop`, and the target branch for the pull request should also be `develop`.
 
 Before your branch can be merged, all the checks described in [Running code checks](#running-code-checks) have to be passing. You can verify that manually by running `./indocker composer ci`, or wait for the build to be run automatically after the pull request is created.
+
+## Architectural Decision Records
+
+The project includes logs for some architectural decisions, using the [adr](https://adr.github.io/) proposal.
+
+If you are curious or want to understand why something has been built in some specific way, [take a look at them](docs/adr).

docs/adr/2021-01-17-support-restrictions-and-permissions-in-api-keys.md

@@ -1,3 +1,50 @@
 # Support restrictions and permissions in API keys
 
+* Status: Accepted
+* Date: 2021-01-17
 
+## Context and problem statement
+
+Historically, every API key generated for Shlink granted you access to all existing resources.
+
+The intention is to be able to apply some form of restriction to API keys, so that only a subset of "resources" can be accessed with it, naming:
+
+* Allowing interactions only with short URLs and related resources, that have been created with the same API key.
+* Allowing interactions only with short URLs and related resources, that have been attached to a specific domain.
+
+The intention is to implement a system that allows adding to API keys as many of these restrictions as wanted.
+
+Supporting more restrictions in the future is also desirable.
+
+## Considered option
+
+* Using an ACL/RBAC library, and checking roles in a middleware.
+* Using a service that, provided an API key, tells if certain resource is reachable while it also allows building queries dynamically.
+* Using some library implementing the specification pattern, to dynamically build queries transparently for outer layers.
+
+## Decision outcome
+
+The main difficulty on implementing this is that the entity conditioning the behavior (the API key) comes in the request in some form, but it can potentially affect database queries performed in the persistence layer.
+
+Because of this, it has to traverse all the application layers from top to bottom, in most of the cases.
+
+This motivated selecting the third option, as we can propagate the API key and delay its handling to the last step, without changing the behavior of the rest of the layers that much (except in some individual use cases).
+
+The domain term used to refer these "restrictions" is finally **roles**.
+
+It can be combined in the future with an ACL/RBAC library, if we want to restrict access to certain resources, but it didn't fulfil the initial requirements.
+
+## Pros and Cons of the Options
+
+### An ACL/RBAC library
+
+* Good, because there are many good libraries out there.
+* Bad, because when you need to filter resources lists this kind of libraries doesn't really work.
+
+### A service with the logic
+
+* Bad, because it would need to be used in many layers of the application, mixing unrelated concerns.
+
+### A library implementing the specification pattern
+
+* Good, because allows centralizing the generation of dynamic specs by the entity itself, that are later translated automatically into database queries.

docs/adr/README.md

@@ -0,0 +1,5 @@
+# Architectural Decision Records
+
+Here listed you will find the different architectural decisions taken in the project, including all the reasoning behind it, options considered, and final outcome.
+
+* [2021-01-17 Support restrictions and permissions in API keys](2021-01-17-support-restrictions-and-permissions-in-api-keys.md)