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 totrue
- 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:
- The
redirect
service… - Which is injected with the
session.store
… session.store
callsdriver()
on the session immediately- 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:
- Create a brand new Laravel application
- Remove the application key
- Set
session.encrypt
totrue
- 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)
@lindyhopchris If the issue is copying
.env
files, then theAPP_KEY
value can be added as default inconfig/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 anAPP_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 theboot
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.
@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 controlSo 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.