Api: Controller's constructor runs before the middleware

Created on 13 Apr 2016  路  4Comments  路  Source: dingo/api

Most helpful comment

@HtmHell This is something that the framework does on purpose, especially since the framework allows you to define middleware for a controller via its constructor. Because of that, the controller has to be constructed before going through the pipeline.

Coincidentally Taylor actually tweeted about this, with a note to the upgrade guide for 5.3 that speaks to this. Basically, it was never intended to be able to access session data, or the authenticated user in the constructor of the controller. One thing he mentions is (the closure middleware) is 5.3 specific, but you may DI the request object into your controllers method(s) and use the user method to get the authenticated user.

Because of this, not much we can fix on the side of dingo, so I'm gonna close this off. Hope my comment was helpful

All 4 comments

I could be wrong, but I think controller constructor's are supposed to run before the middleware.

The answer on the StackOverflow post seems like it would fix your issue.

@assembledadam On laravel the middleware runs before the controller's constructor, and the answer I've recieved will work, but the issue still exists - If I want to declare the middleware in my routes, like so:

$api->group(['middleware' => 'auth:user'], function() use($api)
{
    $api->get('account', ['as' => 'user.account', 'uses' => 'UserAccountController@index']);
    ...

The constructor of UserAccountController will run before the middleware, and I will not be able to do something like that:

public function __construct()
{
    $this->user = \Auth::user();
    ...

@HtmHell This is something that the framework does on purpose, especially since the framework allows you to define middleware for a controller via its constructor. Because of that, the controller has to be constructed before going through the pipeline.

Coincidentally Taylor actually tweeted about this, with a note to the upgrade guide for 5.3 that speaks to this. Basically, it was never intended to be able to access session data, or the authenticated user in the constructor of the controller. One thing he mentions is (the closure middleware) is 5.3 specific, but you may DI the request object into your controllers method(s) and use the user method to get the authenticated user.

Because of this, not much we can fix on the side of dingo, so I'm gonna close this off. Hope my comment was helpful

@hskrasek -- I also notice this issue. I'm on Laravel 5.2, as soon as I updated my packages, I experience this issue. I also tried the solution from the SO and it doesn't work for me.

Below are the updated packages:

  - Removing psr/log (1.0.0)
  - Installing psr/log (1.0.1)
    Downloading: 100%

  - Installing webmozart/assert (1.1.0)
    Loading from cache

  - Installing phpdocumentor/reflection-common (1.0)
    Loading from cache

  - Installing phpdocumentor/type-resolver (0.2)
    Loading from cache

  - Removing phpdocumentor/reflection-docblock (2.0.4)
  - Installing phpdocumentor/reflection-docblock (3.1.0)
    Loading from cache

  - Removing dingo/blueprint (v0.1.6)
  - Installing dingo/blueprint (v0.2.0)
    Loading from cache

  - Removing dingo/api (v1.0.0-beta3)
  - Installing dingo/api (dev-master 242411e)
    Loading from cache
Was this page helpful?
0 / 5 - 0 ratings

Related issues

cristiammercado picture cristiammercado  路  3Comments

pongz79 picture pongz79  路  4Comments

yaoshanliang picture yaoshanliang  路  4Comments

jdforsythe picture jdforsythe  路  3Comments

jhayiwg picture jhayiwg  路  3Comments