Modifications du paramètre d’injection du constructeur de l’API REST Adobe Commerce - Guide du développeur des commerçants
Adobe Commerce et Magento Open Source ont introduit des modifications dans la façon dont les API REST gèrent l’injection de paramètres de constructeur. Cette mise à jour renforce le cadre de l’API web en veillant à ce que seuls les types de données appropriés soient utilisés dans les requêtes API. Cet article répond également aux questions relatives à CVE-2025-54236.
Description description
Environnements
Adobe Commerce/Magento Open Source 2.4.4+, 2.4.5+, 2.4.6+, 2.4.7+, 2.4.8+, 2.4.9-alpha3 (tous les types de déploiement)
Problème
Amélioration de la validation du type de données de l’API Adobe Commerce - Guide du développeur des commerçants
Vue d’ensemble
Adobe Commerce et Magento Open Source ont introduit des modifications dans la façon dont les API REST gèrent l’injection de paramètres de constructeur. Cette mise à jour renforce le cadre de l’API web en veillant à ce que seuls les types de données appropriés soient utilisés dans les requêtes API. Cet article répond également aux questions relatives à CVE-2025-54236.
Nouveautés
Sécurité des types améliorée dans les API Web
À partir d’Adobe Commerce et Magento Open Source 2.4.4-p16, 2.4.5-p15, 2.4.6-p13, 2.4.7-p8, 2.4.8-p3 et 2.4.9-alpha3, le framework de l’API Web implémente désormais une validation de type de données plus stricte pour les paramètres de constructeur dans les requêtes API. Cette modification permet de s’assurer que :
✅ Les types de données simples (chaînes, entiers, booléens) continuent à fonctionner de manière transparente.
Les interfaces de données API ✅ (Api\Data\*Interface) restent entièrement prises en charge.
Les classes 🚫 Service et les modèles complexes ne sont plus automatiquement instanciés à partir des payloads de l’API.
Détails techniques
Changements
Le ServiceInputProcessor valide désormais plus strictement les paramètres du constructeur pendant le traitement de la requête API. Cette amélioration introduit une couche de validation qui vérifie les types de paramètres avant de tenter une instanciation d’objet. Plus précisément, cette validation se produit dans la méthode getConstructorData() lorsque le système tente de renseigner les paramètres de constructeur à partir des données de payload de l’API. Auparavant, tous les types de paramètre étaient traités ; désormais, seuls les types approuvés sont autorisés.
Types de données autorisés
PRIS EN CHARGE (aucune modification requise) :
Types simples
string- Valeurs de texte, noms de produits, descriptionsint/integer- Valeurs numériques, quantités, identifiantsfloat/double- Nombres décimaux, prix, poidsbool/boolean- Valeurs Vrai/Faux, indicateurs de statut
Interfaces de données d’API
- Tous Classes
*\Api\Data\*Interface
Intégrations potentiellement affectées
Les intégrations personnalisées qui peuvent nécessiter une révision sont les suivantes :
1. Extensions personnalisées et modules tiers
- Extensions envoyant des paramètres de constructeur non standard
- Modules utilisant une injection d’objet complexe dans les payloads d’API
- Points d’entrée d’API personnalisés avec structures de paramètres complexes
2. Scripts de test
- Divers scripts de test avec des payloads complexes
Résolution resolution
Guide de migration
Audit de vos appels API
Inventaire des intégrations actuelles :
- Documentation de l’appel API : consultez tous les points d’entrée API documentés utilisés par votre application.
- Analyse du référentiel de code : recherchez dans la base de code les appels d’API avec des objets imbriqués complexes.
- Analyse du trafic réseau : surveiller les payloads d’API réelles envoyées à Magento.
- Révision de module tiers : vérifiez l’utilisation de l’API dans toutes les extensions installées.
Liste de contrôle d’identification :
- Injection du paramètre du constructeur : rechercher des objets imbriqués dans les payloads de l’API.
- Types d’objets complexes : recherchez les références aux classes ou services de modèles.
- Propriétés personnalisées : identifier les paramètres d’API non standard.
- API spécifiques aux extensions : consultez les implémentations d’API de module personnalisé.
Dépannage
Messages d’erreur courants
Noms de champ non pris en charge pour > 2.4.6
{ "message": "\"{fieldName}\" is not supported. Correct the field name and try again." }
Noms de champ non pris en charge pour < =2.4.6
{ "message": "Property \"{fieldName}\" does not have accessor method \"{methodName}\" in class \"{className}\"." }
Dans ce cas :
- Les paramètres du constructeur utilisant des types complexes sont rejetés.
Étapes de débogage
1. Vérifiez les journaux d’API en mode non développeur (par < =2.4.6).
- Lieu :
var/log/exception.log - Filtrer : rechercher des entrées de
ServiceInputProcessor. - Analyse : recherchez les détails du traitement des paramètres.
2. Tester avec Postman/cURL.
# Test individual API calls curl -X POST "https://your-magento-site.com/rest/V1/products" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_TOKEN" \ -d '{"product":{"sku":"TEST","name":"Test Product"}}'
Compatibilité des versions
Rétrocompatibilité
- Bien que les modifications conservent une compatibilité ascendante globale, des modifications avec rupture peuvent se produire pour les paramètres de l’API REST qui sont des types complexes et n’implémentent pas les interfaces
Api\Data.
API existantes
- Toutes les API Magento standard restent inchangées.
- Aucune modification importante n’est apportée aux fonctionnalités principales.
Extensions personnalisées
- Peut nécessiter des mises à jour si vous utilisez une injection de constructeur complexe.
- Test recommandé avant le déploiement en production.
- Les développeurs d’extensions doivent mettre à jour la documentation.
Intégrations tierces
- Doit être testé minutieusement.
- Contactez les fournisseurs pour obtenir des mises à jour de compatibilité.
- Surveillez l’intégrité de l’intégration après la mise à niveau.
FAQ
Q : Dois-je mettre à jour immédiatement toutes mes intégrations d’API ?
R : Seules les intégrations utilisant l’injection de paramètre de constructeur complexe nécessitent des mises à jour. La plupart des appels d’API standard continuent de fonctionner sans modifications. Privilégiez les intégrations de test et de mise à jour qui utilisent des objets imbriqués complexes dans les payloads d’API.
Q : Comment puis-je déterminer si mon intégration est affectée ?
R : Tester les appels d’API dans un environnement de développement avec la nouvelle version.
Q : Existe-t-il un outil pour migrer automatiquement mes appels API ?
R : Il n’existe aucun outil de migration entièrement automatisé. La plupart des cas impliquent la suppression d’objets imbriqués complexes et l’utilisation de structures de données API appropriées.
Q : Qu’advient-il des appels d’API existants qui ont utilisé une injection complexe ?
R : Ces appels d’API échouent avec une erreur de serveur interne 400 Bad Request ou 500 (par < =2.4.6).
Q : Cette modification affecte-t-elle les API GraphQL ?
R : Non, cette amélioration s’applique uniquement aux requêtes d’API REST via ServiceInputProcessor. Les API GraphQL ne sont pas affectées.
Q : Puis-je temporairement désactiver cette validation pour les tests ?
R : Non, cette validation est intégrée au framework de base et ne peut pas être désactivée. Vous pouvez effectuer des tests sur les anciennes versions de Magento pour vérifier le comportement hérité.
Q : Que dois-je faire si une extension tierce est affectée ?
R : Contactez le fournisseur pour obtenir une version mise à jour et compatible. Si elle n’est pas disponible, envisagez d’autres solutions ou travaillez avec un développeur pour créer une couche de compatibilité.