4.x Error Middleware #2398

l0gicgate · 2018-02-14T18:30:32Z

Preface

The original PR #2222 was closed and some of the concepts and code will be implemented in this PR.

Description

This PR eliminates all native error handlers and replaces it with ErrorMiddleware which handles all errors and provides multiple different renderers (HTML, XML, JSON, Plain Text) to enhance error display.

Implementation

use Slim\App;
use Slim\Middleware\ErrorMiddleware;
use Slim\Middleware\RoutingMiddleware;

$app = new App();

/*
 * The routing middleware should be added earlier than the ErrorMiddleware
 * Otherwise exceptions thrown from it will not be handled by the middleware
 */
$routingMiddleware = new RoutingMiddleware($app->getRouter());
$app->add($routingMiddleware);

/*
 * The constructor of `ErrorMiddleware` takes in 4 parameters
 * @param CallableResolverInterface $callableResolver -> Callable Resolver Interface of your choice
 * @param bool $displayErrorDetails -> Should be set to false in production
 * @param bool $logErrors -> Parameter is passed to the default ErrorHandler
 * @param bool $logErrorDetails -> Display error details in error log
 * which can be replaced by a callable of your choice.
 * Note: This middleware should be added last. It will not handle any exceptions/errors
 * for middleware added after it.
 */
$callableResolver = $app->getCallableResolver();
$errorMiddleware = new ErrorMiddleware($callableResolver, true, true, true);
$app->add($errorMiddleware);

...
$app->run();

Adding custom handlers for different named exceptions

...
$callableResolver = $app->getCallableResolver();
$errorMiddleware = new ErrorMiddleware($callableResolver, true, true, true);

$handler = function ($req, $res, $exception, $displayErrorDetails) {
    return $res->withJson(['error' => 'Caught MyNamedException']);
}
$errorMiddleware->setErrorHandler(MyNamedException::class, $handler);
$app->add($errorMiddleware);

Error Logging

If you would like to pipe in custom error logging to the default ErrorHandler that ships with Slim you can simply extend it and stub the logError() method.

namespace MyApp\Handlers;

use Slim\Handlers\ErrorHandler;

class MyErrorHandler extends ErrorHandler {
    public function logError($error)
    {
        // Insert custom error logging function.
    }
}

use MyApp\Handlers\MyErrorHandler;
use Slim\App;
use Slim\Middleware\ErrorMiddleware;

$app = new App();
$callableResolver = $app->getCallableResolver();

$myErrorHandler = new MyErrorHandler(true); // Constructor parameter is $logErrors (bool)
$errorMiddleware = new ErrorMiddleware($callableResolver, true, true, true);
$errorMiddleware->setDefaultErrorHandler($myErrorHandler);
$app->add($errorMiddleware);

...
$app->run();

Error Handling/Rendering

The rendering is finally decoupled from the handling. Everything still works the way it previously did. It will still detect the content-type and render things appropriately with the help of ErrorRenderers. The core ErrorHandler extends the AbstractErrorHandler class which has been completely refactored. By default it will call the appropriate ErrorRenderer for the supported content types. Someone can now provide their custom error renderer by extending the AbstractErrorHandler class and overloading the protected renderer variable from the parent.

class MyCustomErrorRenderer extends \Slim\Handlers\AbstractErrorRenderer
{
    public function render()
    {
        return 'My awesome format';
    }
}

class MyCustomErrorHandler extends \Slim\Handlers\ErrorHandler
{
    protected $renderer = MyCustomErrorRenderer::class;
}

HTTP Exceptions

I just think it makes sense to throw HTTP based exceptions within the application. These exceptions works with nicely with the proposed native renderers. They can each have a description and title attribute as well to provide a bit more insight when the native HTML renderer is invoked.

The base class HttpSpecializedException extends Exception and comes with the following sub classes :

HttpBadRequestException
HttpForbiddenException
HttpInternalServerErrorException
HttpNotAllowedException
HttpNotFoundException
HttpNotImplementedException
HttpUnauthorizedException

The developer can extend the HttpSpecializedException class if they need any other response codes that we decide not to provide with the base repository. Example if you wanted a 504 gateway timeout exception that behaves like the native ones you would do the following:
I

class HttpForbiddenException extends HttpSpecializedException
{
    protected $code = 504;
    protected $message = 'Gateway Timeout.';
    protected $title = '504 Gateway Timeout';
    protected $description = 'Timed out before receiving response from the upstream server.';
}

Status

Work in progress

Remove Existing Error Handling
Implement Error Middleware
Implement supporting tests
[X ] Discussion and Code Review.

coveralls · 2018-02-14T18:32:52Z

Coverage increased (+1.1%) to 96.055% when pulling 8cefb1c on l0gicgate:4.x-ErrorMiddleware into bd6ef95 on slimphp:4.x.

…ling middleware.

…wed` exceptions while preparing route.

…hod to support http named exceptions.

…dleware`

asheliahut

Just some thoughts.

asheliahut · 2018-02-15T22:51:58Z

Slim/App.php

@@ -555,51 +434,29 @@ public function group($pattern, $callable)
    public function run()
    {
        // create request
-        $request = Request::createFromGlobals($_SERVER);
+        if (is_null($this->request)) {


null === $this->request is better here no overhead of function call.

asheliahut · 2018-02-15T22:52:04Z

Slim/App.php

@@ -682,22 +541,14 @@ public function __invoke(ServerRequestInterface $request, ResponseInterface $res
        $router = $this->getRouter();

        // If routing hasn't been done, then do it now so we can dispatch
-        if (null === $routeInfo) {
+        if (is_null($routeInfo)) {


should stay ===

asheliahut · 2018-02-15T22:52:22Z

Slim/Error/Renderers/HtmlErrorRenderer.php

+            $html = '<p>The application could not run because of the following error:</p>';
+            $html .= '<h2>Details</h2>';
+            $html .= $this->renderExceptionFragment($e);
+        } else {


you can just return before the else and have this html set as a second return lowering cyclomatic complexity by 1.

asheliahut · 2018-02-15T22:52:27Z

Slim/Error/Renderers/HtmlErrorRenderer.php

+    {
+        $html = sprintf('<div><strong>Type:</strong> %s</div>', get_class($exception));
+
+        if (($code = $exception->getCode())) {


if someone passes an exception code of 0 this will never execute.

asheliahut · 2018-02-15T22:52:28Z

Slim/Error/Renderers/HtmlErrorRenderer.php

+            $html .= sprintf('<div><strong>Code:</strong> %s</div>', $code);
+        }
+
+        if (($message = $exception->getMessage())) {


if someone sets a message of '0' it also will fail to run.

asheliahut · 2018-02-15T22:53:14Z

Slim/Handlers/AbstractErrorHandler.php

+     */
+    protected function logError($error)
+    {
+        error_log($error);


I feel like this error log should also be able to take in an outside error logging, as in be able to take in a logger middleware of some kind.

In general, I agree. A separate PR after this could allow for handling a PSR3 logger.

asheliahut · 2018-02-15T22:53:17Z

Slim/Handlers/ErrorHandler.php

+/**
+ * Default Slim application error handler
+ *
+ * It outputs the error message and diagnostic information in either


either-> one of the following

asheliahut · 2018-02-15T22:53:20Z

Slim/Middleware/ErrorMiddleware.php

+         */
+        if (method_exists($exception, 'getRequest')) {
+            $request = $exception->getRequest();
+            if (!is_null($request)) {


asheliahut · 2018-02-15T22:53:24Z

Slim/Middleware/RoutingMiddleware.php

+         * exact state of the request at the time of the exception can be
+         * accessed by the end user if necessary
+         */
+        if (!is_null($exception)) {


asheliahut · 2018-02-15T22:53:29Z

Slim/Error/AbstractErrorRenderer.php

+/**
+ * Default Slim application error renderer
+ *
+ * It outputs the error message and diagnostic information in either JSON, XML,


either should be "one of the following"

l0gicgate · 2018-02-15T23:48:09Z

Thank you @asheliahut for the code review. I'm aware this is a large PR and I really appreciate you going through everything. I have made the suggested changes besides the suggestion you made for the AbstractErrorHandler::logError() method, If people want to implement logging they can simply extend the class and replace the ::logError() method. That's the main reason why I've left it abstract.

odan · 2018-02-17T10:32:52Z

Slim/Error/Renderers/PlainTextErrorRenderer.php

+    {
+        $e = $this->exception;
+
+        $text = 'Slim Application Error:' . PHP_EOL;


Use \n instead of PHP_EOL to make integration tests compatible with windows.

odan · 2018-02-17T10:36:33Z

Slim/Handlers/AbstractErrorHandler.php

+     *
+     * @return ErrorRendererInterface
+     *
+     * @throws \RuntimeException


Add use RuntimeException on top to remove the backslash.

odan · 2018-02-17T10:39:46Z

Slim/Handlers/AbstractErrorHandler.php

+    {
+        $renderer = $this->renderer;
+
+        if ((


There'd be plenty of room to put this statement in one line.
if (($renderer !== null && !class_exists($renderer)) {

odan · 2018-02-17T10:41:18Z

Slim/Handlers/AbstractErrorHandler.php

+     */
+    protected function formatResponse()
+    {
+        $e = $this->exception;


This extra variable ($e) is not really necessary.

odan · 2018-02-17T10:43:38Z

Slim/Middleware/ErrorMiddleware.php

+     * Get callable to handle scenarios where an error
+     * occurs when processing the current request.
+     *
+     * @param string $type


What for values can be passed here?

I don't understand your question. Can you clarify?

odan · 2018-02-17T10:53:59Z

Hi!

I have some questions / ideas about this PR and the error handling in general.

If Slim 4 will provide a new Error middleware like in this PR, why do we still need the setErrorHandler() and setDefaultErrorHandler methods in the App class? There should be only one style how to add middleware to the stack and not multiple different methods. This is important, because I want to decide in which order I place my middleware handlers.
I don't like the PHP_EOL magic constant because the response will be different on windows/linux. The Response should be exactly the same for all platforms.

odan · 2018-02-17T12:42:30Z

The name of the middleware ErrorMiddleware implies that it handles PHP errors. But in PHP there is a small difference between Exceptions and Errors. If this middleware handles "only" Exceptions and no "Errors" then the it should be renamed to "ExceptionMiddleware".

The question is how to handle PHP errors (extended from Throwable)? Are you planning a new separate Middleware (e.g. ErrorMiddleware) or a generic "ThrowableMiddleware" for Exceptions and Errors together?

designermonkey · 2018-02-17T19:55:21Z

Slim/Interfaces/ErrorRendererInterface.php

+     * @param \Exception|\Throwable $exception
+     * @param bool $displayErrorDetails
+     */
+    public function __construct($exception, $displayErrorDetails);


Interfaces should not have a constructor as you are limiting the ability to define implementation detail vs defining expected behaviour.

Instead, your methods render and renderWithBody should accept the exception instance.

Thank you for pointing that out, I will refactor the interface accordingly!

l0gicgate · 2018-02-17T20:00:34Z

@odan

I am going to replace all instances of PHP_EOL to \n. Thanks for pointing that out.
The App class does not contain setErrorHandler() and setDefaultErrorHandler() anymore. The first commit on this PR removes all that.
Definitely open for proper naming suggestion for the middleware's name. It does handle both Exception and Throwble by default.

Thank you for reviewing this PR!

edudobay · 2018-02-17T20:10:38Z

Hi! As I started to point out at #2393, I believe that there should be a separate writeToErrorLog (or similar) setting, that doesn’t need to subordinate to displayErrorDetails. A couple reasons for that:

Newcomers might be confused when they turn of display of error details and things stop going to the error log.
Anyways we might need to keep a log of errors even though they were displayed to the client (maybe the client was an API so we couldn’t really see the output).
Writing to a log and rendering the error to the client seem like separate concerns to me. These could even be dealt with by separate classes; but anyway it seems to me that it would be more logical to have separate settings for separate (independent) behaviors.

If you agree with these concerns, you can refer to #2393 for some remarks I’ve already made and I’ll be happy to help with the implementation. (I already have a draft but it is written for Slim 3.)

edudobay · 2018-02-18T23:49:44Z

Slim/Handlers/AbstractErrorHandler.php

+    protected function writeToErrorLog()
+    {
+        $renderer = new PlainTextErrorRenderer();
+        $error = $renderer->render($this->exception, $this->displayErrorDetails);


Maybe the details should always be displayed in the error log? To me it doesn’t make sense to log a generic "Application error" without details.

(Maybe we are starting to cross boundaries and violating SRP as @odan pointed out?)

You do have a point. I can modify this so it’s always displaying the error details when writing to log if everyone is in favor of this option!

@odan @designermonkey @akrabat @asheliahut @geggleto

On a production server I have to log all errors (into a file), but for security reasons I am not allowed to show the users any error details. Therefore, it is still necessary to be able to configure both options (displayErrorDetails and logging) independently of each other.

For more advanced requirements, I expect that the user should be able to easily replace Slim's error handling with their own.

I don't want this component to turn into a massive thing as we're Slim! However, we should be reasonably flexible.

So how about I decouple $displayErrorDetails from the logging and add another parameter $logErrorDetails which can be enabled or disabled. So for instance you may not want to display the error details to the end user but you may want to have them displayed in your log.

@l0gicgate Sounds good

@odan I've implemented $logErrorDetails in this commit

akrabat · 2018-02-19T08:36:38Z

/*
 * The routing middleware should always be added first
 * before the error handling middleware is added
 */

Why? I want the error handling middleware to be the outermost middleware as there will be other middleware before routing that I want the error handler to pick up.

l0gicgate · 2018-02-19T19:44:06Z

@akrabat what I meant by that is ErrorMiddleware should be the last one to be added. In the example RoutingMiddleware should be added first, but I don't mean that it should be added first in your whole application.

…ogging.

akrabat · 2018-02-25T09:58:13Z

Slim/App.php

@@ -106,6 +87,7 @@ public function __construct(array $settings = [], ContainerInterface $container
     * Get container
     *
     * @return ContainerInterface|null
+     * @codeCoverageIgnore


Why are we ignoring code coverage for methods in App?

Removed and added tests for those methods.

akrabat · 2018-02-25T10:07:07Z

Slim/App.php

     */
-    protected $notFoundHandler;
+    protected $request;


I do not want $request or $response as properties on App. They were intentionally removed from Slim 3's DIC because they are immutable and people use them as if they aren't.

This also means that I don't want set/getRequest() and set/getResponse().

Also, run() and process() are separate for a reason: it allows someone to inject their own request and response when running Silm.

Removed and modified run() signature to take in an optional $request parameter for test purposes.

akrabat

A number of bits and bobs in here to look at @l0gicgate.

If you'd like me to raise a PR against this one addressing them, let me know.

akrabat · 2018-02-25T10:10:41Z

Slim/Middleware/ErrorMiddleware.php

+{
+    /**
+     * @var bool
+     */


Add a gap between each property. It just looks nicer. This applies to all files.

akrabat · 2018-02-25T10:11:49Z

Slim/Middleware/ErrorMiddleware.php

+    public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next)
+    {
+        $this->request = $request;
+        $this->response = $response;


Do not store response. Each renderer should return a response that they have created.

akrabat · 2018-02-25T10:24:33Z

Slim/Middleware/RoutingMiddleware.php

@@ -60,6 +65,21 @@ public function performRouting(ServerRequestInterface $request)

            // add route to the request's attributes
            $request = $request->withAttribute('route', $route);
+        } elseif ($routeInfo[0] === Dispatcher::NOT_FOUND) {
+            $exception = new HttpNotFoundException();


Call $exception->setRequest($request); and then throw directly here.

akrabat · 2018-02-25T10:25:04Z

Slim/Middleware/RoutingMiddleware.php

+            $exception = new HttpNotFoundException();
+        } elseif ($routeInfo[0] === Dispatcher::METHOD_NOT_ALLOWED) {
+            $exception = new HttpNotAllowedException();
+            $exception->setAllowedMethods($routeInfo[1]);


Call $exception->setRequest($request); and then throw directly here.

I know it's a duplication from above, but will be clearer to read and remove the test for not null below.

akrabat · 2018-02-25T10:34:09Z

Slim/Middleware/ErrorMiddleware.php

+        /**
+         * Retrieve request object from exception and replace current request object if not null
+         */
+        if (method_exists($exception, 'getRequest')) {


Test for an instance of HttpException. That way we can be sure that the Request object in getRequest() is a PSR7 Request object.

akrabat · 2018-02-25T11:31:11Z

Slim/Exception/HttpNotAllowedException.php

+<?php
+namespace Slim\Exception;
+
+class HttpNotAllowedException extends HttpException


Rename to HttpMethodNotAllowedException.

akrabat · 2018-02-25T11:35:48Z

Slim/Handlers/AbstractErrorHandler.php

+        $response = $this->response;
+        $body = $this->renderer->renderWithBody($this->exception, $this->displayErrorDetails);
+
+        if ($this->exception instanceof HttpNotAllowedException) {


As the exception should return a response, this can go into the exception itself.

akrabat · 2018-02-25T11:36:35Z

Slim/Handlers/ErrorHandler.php

+ * It outputs the error message and diagnostic information in one of the following formats:
+ * JSON, XML, Plain Text or HTML based on the Accept header.
+ */
+class ErrorHandler extends AbstractErrorHandler


Would rather have an interface and rename AbstractErrorHandler to ErrorHandler

akrabat · 2018-02-25T11:37:05Z

Slim/Interfaces/ErrorHandlerInterface.php

+     */
+    public function __invoke(
+        ServerRequestInterface $request,
+        ResponseInterface $response,


Response not required.

Actually, what if during the middleware progression a user did attach headers to the response, example if a CORS middleware appended headers, wouldn't we want to have the response object that reflects the correct state at the time the time the exception was thrown?

Where does it come from given that the error handler is called from the catch() of the Middleware and that we won't have $response passed into the middleware in PSR-15?

akrabat · 2018-02-25T11:37:34Z

Slim/Interfaces/ErrorRendererInterface.php

+ * @package Slim
+ * @since   4.0.0
+ */
+interface ErrorRendererInterface


I think we just need render which returns a response.

Closes #2398 Fixes #2041 Fixes #2170 Fixes #2393

Fix copyright year

Remove existing error handling and related tests.

d1c1646

l0gicgate changed the title ~~4.x Error Middleware~~ 4.x Error Handling Middleware Feb 14, 2018

l0gicgate changed the title ~~4.x Error Handling Middleware~~ 4.x Error Middleware Feb 14, 2018

l0gicgate added 11 commits February 14, 2018 21:51

Add named http exceptions

174f442

Refactor App::run() and App::__invoke() to support new error hand…

680042a

…ling middleware.

Refactor RoutingMiddleware to throw HttpNotFound and `HttpNotAllo…

74b9c66

…wed` exceptions while preparing route.

Rename RoutingTest to RoutingMiddlewareTest and refactor test met…

d2940f6

…hod to support http named exceptions.

Add error handlers and error renderers

524fb10

Add error handlers and error renderers supporting unit tests

d5e2383

Add http named exception supporting unit tests

921bd02

Add error middleware implementation and supporting unit tests

bf6b979

Fix build errors.

9ffd32c

Reintegrate runner tests in AppTest

f7aac1f

Extend supporting unit tests for AbstractErrorHandler and `ErrorMid…

e34b6a7

…dleware`

asheliahut suggested changes Feb 15, 2018

View reviewed changes

Refactor small code blocks and language structure from peer review.

baac352

This was referenced Feb 17, 2018

Difference between displayErrorDetails and printing to error log #2393

Closed

How to get the container in v4 to output exceptions? #2358

Closed

odan reviewed Feb 17, 2018

View reviewed changes

designermonkey reviewed Feb 17, 2018

View reviewed changes

edudobay reviewed Feb 18, 2018

View reviewed changes

Refactor writeErrorToLog to decouple displayErrorDetails from error l…

897958f

…ogging.

akrabat added the Slim 4 label Feb 25, 2018

akrabat reviewed Feb 25, 2018

View reviewed changes

akrabat requested changes Feb 25, 2018

View reviewed changes

l0gicgate added 9 commits February 26, 2018 00:14

Refactored run() signature and removed codeCoverageIgnore instances

616ae72

Added App tests for removed @codeCoverageIgnore

d260c6b

Fix tests in ErrorMiddlewareTest for refactored App::run() method

44be8d9

Fix requested changes in error renderers

bdfa9cf

Fix requested changes for named http exceptions

c941d53

Rename AbstractErrorHandler to ErrorHandler

5ef90ec

Fix requested changes in ErrorMiddleware and Routing Middleware

aaf0c57

Fix error handling bug in ErrorHandler

c70f71d

Add test coverage for PlainTextErrorRenderer

8cefb1c

akrabat merged commit 8cefb1c into slimphp:4.x Mar 12, 2018

akrabat added a commit that referenced this pull request Mar 12, 2018

Merge branch 'l0gicgate-4.x-ErrorMiddleware' into 4.x

b853541

Closes #2398 Fixes #2041 Fixes #2170 Fixes #2393

l0gicgate added a commit to l0gicgate/Slim that referenced this pull request Mar 13, 2018

Refactor routing middleware reflecting changes from slimphp#2398

e2d52a2

l0gicgate added a commit to l0gicgate/Slim that referenced this pull request May 15, 2018

Refactor routing middleware reflecting changes from slimphp#2398

76d6d37

l0gicgate added a commit to l0gicgate/Slim that referenced this pull request May 17, 2018

Refactor routing middleware reflecting changes from slimphp#2398

ad2e7ce

Fix copyright year

l0gicgate deleted the 4.x-ErrorMiddleware branch July 13, 2018 18:02

l0gicgate mentioned this pull request Jul 13, 2018

4.x HttpSpecializedException Constructor Fix #2468

Merged

This was referenced Sep 16, 2018

Add support for most commons HTTP errors #1965

Closed

Suggestions for error-handling in v4 #2170

Closed

lordrhodos mentioned this pull request Jan 11, 2019

ErrorMiddleware::handleException function passes wrong number of parameters to handler #2564

Closed

l0gicgate mentioned this pull request Apr 25, 2019

Slim 4 Alpha Release #2665

Merged

l0gicgate mentioned this pull request Aug 1, 2019

Slim 4 Release #2769

Merged

akrabat mentioned this pull request May 2, 2024

Add enable-log-details-tip to response body Fixes #3317 #3320

Closed

4.x Error Middleware #2398

4.x Error Middleware #2398

Conversation

l0gicgate commented Feb 14, 2018 • edited

Preface

Description

Implementation

Error Logging

Error Handling/Rendering

HTTP Exceptions

Status

coveralls commented Feb 14, 2018 • edited

asheliahut left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

l0gicgate commented Feb 15, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

odan commented Feb 17, 2018 • edited

odan commented Feb 17, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

l0gicgate commented Feb 17, 2018

edudobay commented Feb 17, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

akrabat commented Feb 19, 2018 • edited

l0gicgate commented Feb 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

akrabat left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

l0gicgate commented Feb 14, 2018 •

edited

coveralls commented Feb 14, 2018 •

edited

odan commented Feb 17, 2018 •

edited

odan commented Feb 17, 2018 •

edited

akrabat commented Feb 19, 2018 •

edited