Make conversion from json to php serialization easier when upgrading to 4.x

Created on 20 January 2024, 11 months ago

Problem/Motivation

In 🐛 RabbitMQ claimItem()->data does not return objects submited to createItem() Fixed I stated "I can not see a way to determine the difference between unserialize() returning FALSE from an error or returning FALSE because the data to be returned was a serialized FALSE."

It turns out there are two ways that I didn't consider.

  1. error_get_last()
  2. Compare the value of the string sent to unseralize()

Option 1 is a bit unstable in that errors insdie could also show up as a false positve.
Option 2 however is simple, we know exactly what a FALSE is when serialized 'b:0;', a simple string comparisson and we know if it was an error or the data fed in was actually false.

Option 2 would allow us to fall back to json to make the upgrade easier.

Steps to reproduce

N/A

Proposed resolution

Fallback to JSON decode when unserialize() returns FALSE;

Remaining tasks

User interface changes

None

API changes

None.

Data model changes

No changes to propsoed, however 'non php serialized' data will be decoded. Perhaps this should be tied to a $settings value to only enable during upgrade phrase.

📌 Task
Status

Active

Version

4.0

Component

Code

Created by

🇺🇸United States cmlara

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @cmlara
  • 🇫🇷France fgm Paris, France

    One issue remains with PHP serialization: it has obvious advantages like speed and being able to (de)serialize class objects, but that it also a security issue because payloads can be crafted that can be dangerous. In comparison, JSON is basically safe by construction.

    Also, it means Drupal can't create jobs to be handled by non-PHP workers, which is getting more common over time (e.g. Go workers).

  • 🇺🇸United States cmlara

    but that it also a security issue because payloads can be crafted that can be dangerous.

    Indeed, that has been the one negative I haven’t liked about converting 4.x to no longer be JSON. Unfortunately it’s what we are forced with until core comes up with a method for queue gets to specify an allowed class (not aware of any feature request for this though perhaps there should be?).

    Also, it means Drupal can't create jobs to be handled by non-PHP workers

    Similar complaint, I haven’t fully embraced 4.x as my only apps using 3.x needed to feed a python consumer. I see Allow serialization mode to be configured per queue. Active as the solution for that (php for most queues, json for specific queues feeding out to 3rd party solutions or ingesting from 3rd parties)

Production build 0.71.5 2024