Encrypter contract has no getKey() method

[smknstd]

• Laravel Version: 8.x
• PHP Version: 8.0
• Database Driver & Version: mysql 8.0

Description:

As reported by @denis-chmel here, contract \Illuminate\Contracts\Encryption\Encrypter has no public getKey() method declared and it probably should as EncryptCookies uses it since this fix.

https://github.com/laravel/framework/blob/8.x/src/Illuminate/Cookie/Middleware/EncryptCookies.php#L86
https://github.com/laravel/framework/blob/8.x/src/Illuminate/Cookie/Middleware/EncryptCookies.php#L148

What do you think ?

[driesvints]

Yeah, this is an issue. I'm not sure how to resolve this properly as you don't really want the getKey method on the encrypter contract. It should be kept simple. Maybe a refactor of the CookieValuePrefix class to contain the app key would be a good idea for Laravel 9.

[X-Coder264]

Why not just inject the key value to the EncryptCookies middleware via the constructor (the same way the encrypter gets its key) ? That seems to be the cleanest approach (especially since the CookieValuePrefix class has only static methods).

[driesvints]

@X-Coder264 because I believe in an ideal scenario, the key is encapsulated in an framework class rather than provided directly to the Middleware.

[X-Coder264]

It's provided directly as a string to the encrypter too. It'd be nice to have it as a class there too then.

[driesvints]

@X-Coder264 no, it's already wrapped in a class there. The encrypter itself.

[X-Coder264]

I don't know what's your definition of "wrapped" but it's different than mine. My idea of wrapped would be to create a Key class which could be typehinted in any constructor (including the Encrypter) which would be resolved out of the container. That way the Key could be used anywhere where it's needed in a Laravel user project without having to copy paste the logic from \Illuminate\Encryption\EncryptionServiceProvider::parseKey each time when we need the key. The Symfony encrypter component which is currently WIP has a similar Key class approach (symfony/symfony#39344) too.

[driesvints]

Yeah maybe. Could be a good idea indeed.

[smknstd]

#38793 (comment) I think it is worth mentioning that adding getKey() method to contract would make it hard to fit with "envelope encryption" like kms as you don't have access to an encryption key. Cookie encryption is probably not a good target for "envelope encryption", but when using the encrypter separately or with an eloquent cast for sensitive data, I think it makes sense.

[driesvints]

@smknstd I think you can just return an empty string in that case.