- Подготовка производственной площадки к маркировке
- Сроки внедрения маркировки для производителей: что нужно знать малым, средним и крупным?
- Оборудование для маркировки: какое нужно и что пригодится из того, что у вас уже есть?
- Состав кода маркировки молочной продукции
Необходимо авторизоваться или зарегистрироваться на портале
API СУЗ 3.0: Создание заказа на эмиссию КМ с открепленной подписью неверного запроса работает без ошибок
POST: <url стенда>/api/v3/order?omsId={omsId}
Согласно документации в заголовках запроса должен присутствовать параметр X-Signature с откреплённой цифровой подписью данных запроса (в формате base64)
Если в качестве значения этого параметра передавать открепленную цифровую подпись неверного (другого) запроса или любых других данных (например, подпись пустой строки), то запрос всё равно отрабатывает без ошибок и возвращает код 200. В теле ответа, при этом, содержится информация о созданном заказе, включая orderId (гуид).
Однако, данный заказ не создается. Это можно проконтролировать в веб интерфейсе в разделе «Управление заказами».
То, что заказ не создается - это логично, т.к. подпись была неверных данных.
А то, что сам запрос вернул код 200 и гуид якобы созданного заказа (orderId) - вызывает сомнение.
А то, что сам запрос вернул код 200 и гуид якобы созданного заказа (orderId) - вызывает сомнение.
Вопрос: Правильное ли поведение СУЗ API, что при подписи неверных данных (X-Signature) запрос отрабатывает без ошибок и возвращает код 200, а в теле ответа orderId указывает гуид «созданного» запроса, который на самом деле не создался?
Тестирование проводилось в песочнице:
https://suz.sandbox.crptech.ru/api/v3/order?omsId=...
«productGroup»: «chemistry»
https://suz.sandbox.crptech.ru/api/v3/order?omsId=...
«productGroup»: «chemistry»
Сначала старые комментарии
Здравствуйте!
По данному вопросу рекомендуем обратиться в службу технической поддержки support@crpt.ru.
01.04.2025 12:42
0
