-
|
Hi, I've just passed a considerable amount of time trying to debug a potential composer issue ( However, turns out you simply can't use I would like to know if this is a known behaviour, maybe it has a very precise reason to work that way? If this behaviour can't be changed, how do you think one could access an envvar inside said callback? Sample of what I would like to do: ->withMiddleware(function (Middleware $middleware) {
$middleware->trustProxies(at: config("trust-proxies.docker-network-ip-range", "172.17.0.0/16"));
})Thanks for your time. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
Laravel suggest caching configs and not using the env inside the app. Interesting how this limitation (that we saw also here https://github.com/laravel/lumen/blob/b18a7652aa2dec5fd96c23693933fef32eca9a88/bootstrap/app.php#L9) comes into place. Would be interesting to see if the old laravel 10 way of bootstrapping the app has this issue. |
Beta Was this translation helpful? Give feedback.
-
|
The old way of setting this up: <?php
namespace App\Http\Middleware;
use Illuminate\Http\Middleware\TrustProxies as Middleware;
use Illuminate\Http\Request;
class TrustProxies extends Middleware
{
public function __construct()
{
$this->proxies = [config("trust-proxies.docker-network-ip-range", "172.17.0.0/16")];
}
}<?php
namespace App\Http;
use Illuminate\Foundation\Http\Kernel as HttpKernel;
class Kernel extends HttpKernel
{
/**
* The application's global HTTP middleware stack.
*
* These middlewares are run during every request to your application.
*
* @var array
*/
protected $middleware = [
// \App\Http\Middleware\TrustHosts::class,
\App\Http\Middleware\TrustProxies::class,
];
...
} |
Beta Was this translation helpful? Give feedback.
-
It doesn't because of order of operations IIRC. I don't remember when exactly the middleware stack gets created without the use of this highly annoying application builder, but the So this Digging into the |
Beta Was this translation helpful? Give feedback.
-
|
@mbabker old way is the best way. |
Beta Was this translation helpful? Give feedback.
-
|
@mbabker thank you very much, it works wonderfully! As always with Laravel, you can do so much more than what's documented. Thank both of you for your time and help! |
Beta Was this translation helpful? Give feedback.
-
|
@macropay-solutions That's a subjective opinion, but not one I disagree with. The builder API (the thing that consolidates it all into this new I feel like the builder is limiting and annoying though if you're trying to do anything beyond using the framework in it's default configuration. By the time I got the builder API's callbacks set up in the way I wanted them in one of my applications with my routing and middleware configurations (as this is an app with a stateless frontend so no sessions except for the Filament backend which is on a separate subdomain, and there's a GitHub app integration so that route group also has cookie and session related middleware disabled), I honestly feel like I would've been better leaving the app on the L10 skeleton and I probably never would've tried it if I were just starting a Laravel application on the new skeleton. |
Beta Was this translation helpful? Give feedback.
It doesn't because of order of operations IIRC. I don't remember when exactly the middleware stack gets created without the use of this highly annoying application builder, but the
withMiddleware()callback is run after the kernel is resolved from the container, which comes before the kernel call's the application'sbootstrapWith()method with its bootstrapper list. The kernel bootstrappers include tasks such as loading the configuration, registering the core service providers, and early setup tasks like that.So this
withMiddleware()callback is going to be run at a point before the framework…