[5.7] Queued Closures - #25777
Conversation
This reintroduces a feature that was previously present in early versions of Laravel queues. However, there have been improvements to serializable closure libraries in the meantime which allows for better security and better handling of Eloquent models and collections. Namely, signing closures with a hash to prevent modification and arbitrary code execution, as well as transforming and resolving models and collections to ModelIdentifier instances.
|
@taylorotwell Any chances of serializing closure routes now that you added a library for serializing closures? |
|
People would need to do measurements to see if the cost of unserializing all the Closures outweighs the benefits of the caching. That's probably for another thread. Would prefer to keep this limited only to feedback on the PR. |
I'm pretty sure the previous implementation also supported this? :P |
| */ | ||
| protected function registerOpisSecurityKey() | ||
| { | ||
| if (Str::startsWith($key = config('app.key'), 'base64:')) { |
There was a problem hiding this comment.
The config function exists in the foundation namespace, so queue shouldn't really depend on it if we want to continue to allow the queue package to be required by arbitrary software projects. Also, the duplication of the base64 decoding logic is a bit gross.
4 participants
This reintroduces a feature that was previously present in early versions of Laravel queues. However, there have been improvements to serializable closure libraries in the meantime which allows for better security and better handling of Eloquent models and collections. Namely, signing closures with a hash to prevent modification and arbitrary code execution, as well as transforming and resolving models and collections to ModelIdentifier instances.