framework: Cannot generate an app key if session is encrypted and a response macro exists

  • Laravel Version: 5.4.32
  • PHP Version: 7.0.18
  • Database Driver & Version: n/a

Description:

An application with these three things:

  • session.encrypt config set to true
  • A response macro registered in a service provider boot method
  • No application key (e.g. because you’ve just cloned an existing application from your team’s version control).

You cannot run any Artisan commands (including key:generate) because you get the following error:

[RuntimeException]                                                                        
The only supported ciphers are AES-128-CBC and AES-256-CBC with the correct key lengths. 

Looking at the stack trace it’s because resolving the responses factory to register the macro results in the following being resolved out of the container:

  1. The redirect service…
  2. Which is injected with the session.store
  3. session.store calls driver() on the session immediately
  4. Which results in the encrypted session being created, injected with the encrypter: https://github.com/illuminate/session/blob/master/SessionServiceProvider.php#L47

As well as causing the above problem, this also all seems very costly just to register a response macro. I’m thinking somewhere in the chain something needs to be injected with the container and only resolve the things it needs when it actually needs them. My suggestion would be the responses factory or the redirector.

If you advise what in the chain should change, I’d be willing to work on a PR for a fix.

Steps To Reproduce:

  1. Create a brand new Laravel application
  2. Remove the application key
  3. Set session.encrypt to true
  4. Add the following to your AppServiceProvider::boot() method:
    public function boot()
    {
        Response::macro('caps', function ($value) {
            return Response::make(strtoupper($value));
        });
    }

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 23 (7 by maintainers)

Most upvoted comments

@lindyhopchris If the issue is copying .env files, then the APP_KEY value can be added as default in config/app.php by updating 'key' => env('APP_KEY') to 'key' => env('APP_KEY', 'SOMEKEY'), so the error you are referring to doesn’t exists. You always need to have an APP_KEY

I am able to reproduce this on a Laravel 8.0 installation, being caused as before by trying to register a Response macro in the boot method of a service provider.

I was able to get around it by wrapping my response macros in a callback to only register them when the response factory is resolved.

        Illuminate\Support\Facades\Response::resolved(function(Illuminate\Contracts\Routing\ResponseFactory $response) {
            $response->macro(...);
        });

@lindyhopchris - I think @srmklive means to put a generic default dev app_key - which is overridden by your production .env - so there is no issue around version control

So I guess the question is; should response macros work on CLI commands? i.e. if you are calling from the CLI - then are you expecting a response macro to kick in at all?

If the answer is no - then we just do a CLI check before registering the macro.

If the answer is yes - then it is a “chicken/egg” problem - and the only way to solve is the manual copying of an app_env key.

Yes. The error will show because you don’t have an App Key. So I don’t see this as a bug if you remove the app key.