Slim 4 Release See the full release notes.

Before doing anything read the docs I just finished the first draft of the docs for Slim 4 which are available here. I need feedback please: https://www.slimframework.com/docs/v4

Download the 4.0.0 release composer require slim/slim:^4.0

Install a PSR-7 Implementation You will also need to install a PSR-7 implementation and ServerRequestCreator combo. You can use Slim's PSR-7 Implementation or choose one of the ones described on the 4.x branch README: https://github.com/slimphp/Slim/blob/4.x/README.md composer require slim/psr7

You can also use the Slim 4 DDD API Skeleton to create a new project composer create-project slim/slim-skeleton [my-app-name]

If you have any questions don't hesitate to ping me on Slack or ask questions in this thread directly, I'm available to help!

I was half way on my project. And I tried to put it on live hosting. And now, I encountered a problem that when I use my login page, and submit the form.. It didn`t redirect to any page, instead it returned me the same routing page with a blank content/page.

I have a scenaro..

https://github.com/slimphp/Slim/blob/master/Slim/Middleware/SessionCookie.php#L127

Generally, it's a bad idea to blindly unserialize() user-controllable input.

https://www.owasp.org/index.php/PHP_Object_Injection

EDIT - for people who don't want to read the whole thread:

The SessionCookie class is not used by default, you have to actually write your application to use it. So this means that the unserialize() -> RCE possibility is only for the select few apps that explicitly use this feature. The default is the native session driver, which is of course not vulnerable.

The default Nginx value of SCRIPT_NAME parameter sent to PHP-FPM is: fastcgi_param SCRIPT_NAME $fastcgi_script_name; https://github.com/nginx/nginx/blob/master/conf/fastcgi_params#L7

The default value of $fastcgi_script_name is a request URI. http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#variables

In the same time Slim sets the BasePath setting to $_SERVER['SCRIPT_NAME'] here: https://github.com/slimphp/Slim/blob/3.x/Slim/Http/Uri.php#L209

A router substracts the basepath from the URL https://github.com/slimphp/Slim/blob/3.x/Slim/Http/Uri.php#L216 The router receives "/" as the URI for any request, and so it misses all routes except of "/".

More of a question than an issue, but what versions of PHP are to be supported by Slim 4? Has dropping PHP 5 support in the new major version been considered?

Slim 4 Alpha Release See the full release notes

Before doing anything read the docs I just finished the first draft of the docs for Slim 4 which are available here. I need feedback please: http://dev.slimframework.com/docs/v4

Download an test the 4.0.0-alpha release You may also play around with the 4.x branch and create a simple app with it to test things out. composer require slim/slim:4.0.0-alpha

Install a PSR-7 Implementation You will also need to install a PSR-7 implementation and ServerRequestCreator combo. You can use Slim's PSR-7 Implementation or choose one of the ones described on the 4.x branch README: https://github.com/slimphp/Slim/blob/4.x/README.md composer require slim/psr7:dev-master

Slim 4 DDD API Skeleton Prototype I also just created a Slim4 Skeleton with a DDD style directory structure with example files and test coverage for everything. I'm not sure if it's the right fit yet as it may be a bit too opinionated but I'd love some feedback:

git clone https://github.com/l0gicgate/Slim-Skeleton
git checkout 4.x

If you have any questions don't hesitate to ping me on Slack or ask questions in this thread directly, I'm available to help!

This PR addresses issue #748 by passing the \Slim\Slim application object to the controller constructor.

Just add something like the following to your controller class and \Slim\Slim object will be available within your controllers.

/**
 * Constructor
 * @param \Slim\Slim $application The Slim application
 */
public function __construct(\Slim\Slim $application)
{
    $this->app = $application;
}

Slim 3 currently uses a Last In, First Out (LIFO) model for middleware.

That is:

$app->add('middleware3');
$app->add('middleware2');
$app->add('middleware1');

will execute the middleware in the order:

1. middleware1
2. middleware2
3. middleware3

This works if you imagine middleware as layers of an onion and adding a new middleware adds a new layer to the outside of the onion.

An alternative, would be to use First In, First Out (FIFO) model.

This is, the same PHP code would execute the middleware in this order:

1. middleware3
2. middleware2
3. middleware1

This works if you imagine middleware as a pipleline going from top to bottom where the first one you add is the first one that's executed, then the second one added is executed, etc.

Should Slim 4 change to the FIFO model?

Here are some intiial thoughts:

• [BC break] Extract Slim\Http into separate PSR-7 component (ONLY PSR-7 methods)
• [BC break] Create custom decorator classes to hold Slim-specific additions to PSR-7
• Accommodate additional media type parsers in request
• Address issues reported by Phan
• Improve test coverage

Additional ideas:

• [BC break] Remove Request, Response and Env from container (@akrabat)
• [BC break] Don't set content-length by default. Provide a middleware for people to use if they want to. (@akrabat)
• Make it faster (or at least don't slow it down!) (@Cyrille37)
• [BC break] Removing Method-Override and providing a middleware (@geggleto)
• [BC break] Decide if we need subRequest at all (@codeguy/@silentworks/@geggleto)
• Lazy resolve route middlewares (#1635) We already do this with route callable(only resolve the matched one). (@mathmarques)
• Look at __invoke and run on App and see if we can consolidate functionality and make them easier to unit test. (@geggleto)
• [BC break] Consolidate error handlers for exceptions and PHP 7 errors (@akrabat)
• Can we avoid statics in Slim\Http? See #1850 (@Raistlfiren)
• [BC break] Look at pathFor()'s parameters? see #1800 (@akrabat)
• [BC break] Do something about basePath from Request. Maybe middleware solution instead? (@akrabat)
• [BC break] Remove determineRouteBeforeDispatch and make routing a middleware that can be placed where you want it to be. If you don't add it yourself, we would add it immediately before dispatch. (@akrabat)
• Use getallheaders() to get the Authorisation header. (irc channel)
• Move documentation into main repo and publish to website on each new release. That way we can insist on documentation with the PR.
• [BC break] Either rename Slim\Exception\SlimException or remove it.

Please add additional thoughts below.

Description As discussed on issue #2170 I feel that the error handling has always been a bit clunky and very tightly coupled to the rendering of the error. This PR eliminates all native error handlers and replaces it with ErrorHandler which handles all errors. You can create a handler for any exception in these ways:

/*
 * Via Shortcut Method
 * Notice that the callable also gets passed $displayErrorDetails optionally from the App settings
 * You can either pass a callback or a resolvable callable as the second parameter
 * My implementation uses CallableResolver when 
 */
$handler = function ($req, $res, $exception, $displayErrorDetails) {
    return $response;
};
$app->setErrorHandler(\Your\Namespaced\Exception::class, $handler);

/*
 * Via Named Shortcut Methods Currently NotFound and NotAllowed only
 */
$app->setNotFoundHandler(function ($request, $response, $exception) {
    return $response;
});

/*
 * Via App Settings
 */
$app = new \Slim\App([
     /*
      * The default error handler can be set using this variable
      * or the $app->setDefaultErrorHandler() method
      * All exceptions are caught by this handler by default which is an instance of ErrorHandler
      */
    'defaultErrorHandler' => function ($req, $res, $exception, $displayErrorDetails) {
       return $res->withJson(['Oops...']);
    },

     /*
      * You can also set multiple error handlers via the settings object
      * by passing an associative array with 'Namespace\Exception' => function () {}
      * You can also pass a resolvable callable since this PR implements CallableResolver
      */
    'errorHandlers' => [
       \Slim\Exceptions\HttpNotFoundException::class => function (...) {...},
       \Your\Namespaced\Exception::class => ResolvableCallable::class
    ]
]);

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\AbstractErrorHandler
{
    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 HttpException extends Exception and comes with the following sub classes :

• HttpBadGatewayException
• HttpBadRequestException
• HttpForbiddenException
• HttpInternalServerErrorException
• HttpNotAllowedException
• HttpNotFoundException
• HttpNotImplementedException
• HttpUnauthorizedException

The developer can extend the HttpException 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 HttpException
{
    protected $code = 504;
    protected $message = 'Gateway Timeout.';
    protected $title = '504 Gateway Timeout';
    protected $description = 'Timed out before receiving response from the upstream server.';
}

Status

• [x] Build Passing
• [x] Unit Tests (Coverage Increased +2.03%)
• [ ] Discussion and Code Review.

These are the cases covered:

Single routes:

| Route URI | Final pattern registered with router | | --- | --- | | '/foo' | /foo | | '/foo/' | /foo/ | | 'foo' | /foo | | '/' | / | | '' | / |

Route groups:

| Group 1 | Group 2 (if exists) | Route URI | Final pattern registered with router | | --- | --- | --- | --- | | '/foo' | | '/bar' | /foo/bar | | '/foo' | | '/bar/' | /foo/bar/ | | '/foo' | | '/' | /foo | | '/foo' | | '' | /foo | | '/foo' | '/baz' | '/' | /foo/baz | | '/foo' | '/baz' | '' | /foo/baz | | '/foo' | '/baz' | '/bar' | /foo/baz/bar | | '/foo' | '/baz' | '/bar/' | /foo/baz/bar/ | | '/foo' | '/' | '/bar' | /foo/bar | | '/foo' | '/' | 'bar' | /foo/bar | | '/foo' | '' | '/bar' | /foo/bar | | '/foo' | '' | 'bar' | /foo/bar | | '/' | | '/bar' | /bar | | '/' | | '/bar/' | /bar/ | | '/' | | '/' | / | | '/' | | '' | / | | '/' | '/baz' | '/' | /baz | | '/' | '/baz' | '' | /baz | | '/' | '/baz' | '/bar' | /baz/bar | | '/' | '/baz' | '/bar/' | /baz/bar/ | | '/' | '/' | '/bar' | /bar | | '/' | '/' | 'bar' | /bar | | '/' | '' | '/bar' | /bar | | '/' | '' | 'bar' | /bar | | '' | | '/bar' | /bar | | '' | | '/bar/' | /bar/ | | '' | | '/' | / | | '' | | '' | / | | '' | '/baz' | '/' | /baz | | '' | '/baz' | '' | /baz | | '' | '/baz' | '/bar' | /baz/bar | | '' | '/baz' | '/bar/' | /baz/bar/ | | '' | '/' | '/bar' | /bar | | '' | '/' | 'bar' | /bar | | '' | '' | '/bar' | /bar | | '' | '' | 'bar' | /bar |

Routes and Route Groups are expected to always start with a slash /.

Related to #1578

Feedback welcome @akrabat @designermonkey @geggleto @dopesong

In Slim 3, the trace of an exception is rendered in JSON response (see Slim/Handlers/PhpError::renderJsonErrorMessage). In Slim 4, the field trace is missing (see Slim/Error/Renderers/JsonErrorRenderer:: formatExceptionFragment). Was this change intentional? Otherwise, please add the field trace again.

Hi!

The arguments get decoded twice, in:

• \Slim\Routing\RoutingResults::getRouteArguments
• \Slim\Routing\RouteResolver::computeRoutingResults

That's a problem if the argument contains a "decodable" combination of characters.

Let's say I have an article with id 9%65. The route to retrieve it is /articles/{id}.

If I rawurlencode the article id (i.e. /articles/9%2565), since it gets decoded twice, the argument returned is 9e instead of 9%65.

In order to get the proper argument, I'd need to rawurlencode the article id twice (i.e. /articles/9%252565)

Please advise

I was in the process of migrating my web application to use the Slim RequestResponseNamedArgs controller invoker in favor of the previous PHP-DI/Invoker-based one I was using, and I had expected that the transition would be a fairly straightforward one, but I'm running into one big issue: if you type a parameter in a controller action, for example as an int, it can never coerce into that value:

<?
$app->get('/test', function($request, $response, int $id) {
    // This will fail with RequestResponseNamedArgs
});

The reason this fails is because, at least per my own research, there's no way to specify that a route parameter should be cast as an integer, even if it only accepts numeric values per its FastRoute config. Because declare(strict_types=1) is set on the RequestResponseNamedArgs class, it won't coerce the always-string values for parameters to fit the typed argument in the action.

I'm not sure what the elegant solution to this is. You could remove the strict typing from that single class, since any type strictness originates from the calling file and this would allow type coercion...or somehow let FastRoute know that it should be parsing some parameters as integers.

I'm not even sure that it's something you'd want to fix on the framework side at all, instead choosing to say that every passed parameter will be a string because, well, URLs are strings. That's certainly what my immediate resolution will be, just to re-type all of those action arguments as strings and parse them down the line.

PHP 8.0+ allows you to use attributes for classes and methods. As a long-time slim user, I thought about implementing attributes in order to define routes.

Instead of writing

$app->get("/users/", "function", $middlewares);

, we then could directly write code like this:

#[Controller(route: "/users", middlewares: [AuthenticationMiddleware::class])]
class UserController extends AbstractController {

    #[Endpoint(method: RequestMethodInterface::METHOD_GET, route: "/", middlewares: [])]
    public function get(Request $request, Response $response, array $args): Response {
        ...
    }

}

Is this something that could be implemented in Slim as a feature?

When I launch functional tests I don't need exception trace log output because Its huge. I want to see only an exception type, code, message, file and line. So I decided to override the formatExceptionFragment method (remove 4 strings forming trace output) of PlainTextErrorRenderer. But the method is private and called from the __invoke method. And so I cant override formatExceptionFragment in child class - to do it - I should also copy __invoke to child class. But then there is no point in inheritance either - you get a separate class, almost identical to PlainTextErrorRenderer, except for 4 lines.

It seems redundant to me to copy almost all the code from PlainTextErrorRenderer just to remove the 4 lines of code responsible for the trace output. Is it possible to change private visibility to protected of the formatExceptionFragment method?

When logging errors in Slim\Handlers\ErrorHandler logError the logger object is declared to implement the LoggerInterface and the error function of this interface is used to actually log the error:

    protected function logError(string $error): void
    {
        $this->logger->error($error);
    }

The LoggerInterface error method has an optional second parameter named context that can be an array of anything. Supplying the exception in this array would improve error logging for some LoggerInterface implementations, e.g. with Monolog you could decide to log different kinds of exceptions differently, without the exception in the context this is not possible.

The only change needed would be:

    protected function logError(string $error): void
    {
        $this->logger->error($error, [ "exception" => $this->exception ]);
    }

Would it make sense to add this?