Я о другом , я о том что как оказалось порядок именованых полей имеет значение , типа передаём в форме name первым e-mail вторым , и если поменяется порядок то все сломается , дело не в подписи а в порядке пунктов при передаче формы. Хотя как бы причём тут это. Ведь на бекенде можно получать их в любом порядке , обращаясь к ним по имени. Допустим тот же перл сортирует хеши как по кайфу , и получается что  даже указав правильный порядок получаю баг ) из-за внутренней реализации хешей. Но какой в этом смысл если а пи написано передавайте эти поля , и подпись, подпись формируется верно, а вот перестановка полей в форме ломает систему ) мне кажется это глупость , a=1&b=2 и b=2&a=1 в их случае дадут разную подпись 😞

Так как после разбора а всегда будет 1 а б всегда будет 2

Ты, кажется, не понял. Подписать можно только конкретный набор полей, упорядоченный. И или в доке написано, что набор полей при подписи нужно как-то отсортировать (и указано как) или порядок полей важен.
У вас в команде есть хоть один миддл? Пусть объяснит.

постоянно видел в платежах что  даже в json поля - надо считать чексумму в определенном порядке..
и если чего перепутали шляпа, и долгие мучения при интеграции

Я вас прекрасно понимаю, формирование подписи зависит от порядка ключей , доеду до дома напишу. А вы видимо уже так улетели в небеса что стали переходить на личности

У @swswsw202 в целом склонность переходить на личности, как мне кажется.

ни GET ни POST запросы не гарантируют вам порядок передачи-приема параметров. а в документации на платежный сервис обычно четко написано в каком порядке считать и как считать подпись (как минимум в паре десятков тех, что я видел - было так)

Я про тоже ) а они просяТ порядок именно в посте , я даже пошёл дальше решил ну ладно раз они меняются местами в посте, я их поменял местами и в генераторе подписи и знаете сработало ) то есть на их стороне подпись берет позиции из тела поста, а не по именам параметров

после нескольких лет (оказалось 10+) с двумя кусками железа пришел к тому, что:
- все мессенджеры и т.д. на одном телефоне (пусть будет айфон последней предпоследней модели). телега умеет сама несколько акков, ватсап умеет два приложения, остальное (типа слака) для личного не нужно то.
- телефон всегда в беззвучном (кроме случаев когда могу не услышать), уведомления включены на личные аккаунты, на рабочих только счетчики новых сообщений
- для позвонить для рабочего завел (откопал в ящике) нокию 71-ю. думаю и ее заменить переехав на е-сим (айфон успешно умеет). таким макаром рабочий можно выключить в любой момент.
- и да - в силу специфики не беру трубку с неизвестных номеров, пока ничего в этом не потерял (кто хочет может написать сообщение, представиться).

Мне кажется что они там оптимизировали авторизацию , и отказались от Толстой функции разбора тела запроса , и сами регекспом режут на части, потому порядок оказался важен

мне кажется там дебилы. ну время покажет

даже через RegExp можно получить вне зависиммости от порядка - руки из нужного места надо использовать

Скорее всего, там ребята пользуют тело запроса как raw - отсюда и зависимость от порядка. А делать так могут как раз с целью оптимизации парсинга запроса. “Выгоднее” заставить клиента прислать запрос в нужном формате (вплотьт до порядка) и тем самым снизить серверное время исполнения запроса. Есть товарищи, которые исходят именно из подобных предпосылок

Штош , придется мне опуститься на более низкий Уровень в своём языке , что бы контролировать тело запроса

🌟 Денис Ильиных 🏂 💻 has reached level 2!

не гарантируют, но при этом, в raw я получу ровно то, что было отправлено и именно в том же порядке.

Так же, как в GET “нельзя” оттправить тело запроса, но я могу его отпраавитть и, если нигде по пути не найдётся умник, который для GET на файрволах режет body, то и прочитать на сервере это тело запроса

только ничего они не выигрывают

Спасибо , мотивация из понЯтна ) думаю воевать с ними бессмысленно , процессорное время дороже одинокого клиента с болью )

Ну, а еще видимо боль клиента не настолько большая, раз клиент не отказывается от них :)

Остальные места писали не индусы ) там все хорошо )👌 но подумаем

Там проблемы не в порядке полей (тут все нормально), а в md5 и вообще аутентификации по подписи и использовании form, а не нормального json api.
Но для старых или ориентированных на простой web апишечек - это нормально.