Find a way to allow unserialize classes

Created on 15 December 2023, 11 months ago
Updated 7 May 2024, 7 months ago

Problem/Motivation

After updating to the latest version, I detected that unserialization for our classes during sitemap generation do not work so it causes fatal error. 📌 unserialize() is insecure unless allowed classes are limited. Use a safe format like JSON or use the allowed_classes option. Fixed

So we can see error like that:
... __PHP_Incomplete_Class given

Steps to reproduce

Proposed resolution

Add a method to define allowed classes that can be unserialized.

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Closed: works as designed

Version

4.0

Component

Code

Created by

🇵🇱Poland lamp5 Rzeszow

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

Comments & Activities

  • Issue created by @lamp5
  • Please check, it's my first patch

  • 🇩🇪Germany gbyte Berlin

    @lamp5 Please explain in more detail what and why is getting unserialized?

    @Ihnatsevych This would simply undo 📌 unserialize() is insecure unless allowed classes are limited. Use a safe format like JSON or use the allowed_classes option. Fixed and I don't think it's what we want.

  • @gbyte
    This patch doesn't introduce anything new, but it allows other modules to reference the complete unserialized classes, as it was in previous versions of the module.
    Since I am not facing the problem described in the parent issue, this patch helps me generate sitemaps

  • 🇵🇱Poland lamp5 Rzeszow

    Few years ago we decided to use simple_sitemap for our project. We are generating a few types of sitemap so we have few of plugin managers to mange types. In our case, we serialized class objects to simple_sitemap queue items and after this update our whole sitemap system stopped working. It was a reason why I opened this issue to find a smart way without patches like we can see here and without expensive refactor of our project.

  • 🇧🇪Belgium kriboogh

    We are also experiencing this issue with core Media classes being stored in the queue items.
    The patch #4, works as a workaround.

  • 🇧🇪Belgium kriboogh

    After re-reviewing this, we updated our UrlGenerator plugin to not store the actual entities in the queue items as this wasn't a good idea in the first place I think. We now just store the entity id in the queue item and load each entity on-demand when the queue item is processed.

  • 🇩🇪Germany gbyte Berlin

    @kriboogh Please provide a merge request with your changes.

  • 🇧🇪Belgium kriboogh

    @gbyte, well actually we don't need the patch anymore, because I rewrote our code to deal with the queue differently.
    (But it was the patch from @Ihnatsevych #4 that initially worked).

  • 🇩🇪Germany gbyte Berlin

    @gbyte, well actually we don't need the patch anymore, because I rewrote our code to deal with the queue differently.

    Ah got you - it's your plugin that you rewrote. I was asking for a patch because I was under the impression you were referring to one of the default plugins (which I remember have not been storing entities in the queue for a long time).

  • 🇵🇱Poland lamp5 Rzeszow

    I also rewrote my whole project to avoid serialize objects of class so we can mark this issue like "works as designed"

  • Status changed to Closed: works as designed 7 months ago
Production build 0.71.5 2024