Не срабатывает API запрос от сервера авторизации к GSM шлюзу?

Question

[greensid]

Пытаюсь организовать доступ к wifi сети организации через локальный сервер авторизации WNAM на базе debian9. Авторизация клиента происходит по коду из смс. Раньше использовали сторонний смс провайдер, а сейчас поставли свой gsm шлюз Yeastar TG100. API на отправку смс для него выглядит следующим образом:

http://x.x.x.x/cgi/WebCGI?1500101=account=xxx&password=xxx&port=1&destination=xxxxxxxxxxx&content=Ваш+код+для+доступа+в+интернет:+xxxx

Если делать запрос через браузер, то все прекрасно работает и смски от шлюза приходят без проблем. Но вот при отправке запроса с сервера не происходит ничего. На шлюзе никакой информации о попытке отправить смс не появляется. Залез в логи сервера и наблюдаю следующую ситуацию:

url=http://x.x.x.x/cgi/WebCGI, data=password=xxx&port=1&destination=xxxxxxxxxxx&content=Ваш+код+для+доступа+в+интернет:+xxxx

Могу ошибаться, но насколько я понимаю, то при отправке, он просто взял и отрезал кусок 1500101=account=xxxв результате чего запрос просто отваливается еще до этапа авторизации (1500101 - параметр для отправки смс, 1500102 - для ussd).
Т.к. в апи не силен, то после долгих танцев с бубном выяснил что триггер происходит именно на 150101, поскольку если, например, добавить & перед account, то он уже попадает в data. А вот с 150101 такой фокус уже не срабатывает и он все равно отрезается как ни старайся.

Еще раз уточню что запрос напрямую через браузер нормально срабатывает и смс стабильно приходят.

При этом в гайде WNAM'а есть аналогичный пример для Kazinfoteh:

http://212.124.121.186:9501/api?action=sendmessage&username=MyUserName&password=MySecretPassword&recipient=%PHONE%&messagetype=SMS:TEXT&originator=INFO_KAZ&messagedata=Код доступа в Интернет: %CODE%

но там при в логах сервера ничего не обрезается:

url=http://212.124.121.186:9501/api, data=action=sendmessage&username=MyUserName&password=MySecretPassword&recipient=79123456789&messagetype=SMS%3ATEXT&originator=INFO_KAZ&messagedata=%D0%9A%D0...

Хотелось бы вообще понять это косяк на стороне сервера или на стороне шлюза, или это такая особенность работы API? В какую сторону копать вообще?

Заранее благодарен за помощь!

Comments

[Valentin Barbolin]

> взял и отрезал кусок 1500101=account=xxx
? - разделяет URL и DATA в http запросе, так что никакой ошибки нет

Попробуй для начала выполнить с сервера запрос curl

curl -X POST http://212.124.121.186:9501/api, data=action=sendmessage&username=MyUserName&password=MySecretPassword&recipient=79123456789&messagetype=SMS%3ATEXT&originator=INFO_KAZ&messagedata=%D0%9A%D0...

[greensid]

Andrey Barbolin, понятно что ? разделяет URL и DATA в запросе, вопрос был не в этом. Если внимательно посмотреть, то в запросе

http://x.x.x.x/cgi/WebCGI?1500101=account=xxx&password=xxx&port=1&destination=xxxxxxxxxxx&content=Ваш+код+для+доступа+в+интернет:+xxxx

есть параметр 1500101=account=xxx. А в логе сервера

url=http://x.x.x.x/cgi/WebCGI, data=password=xxx&port=1&destination=xxxxxxxxxxx&content=Ваш+код+для+доступа+в+интернет:+xxxx

в data параметр 1500101=account=xxx отсутствует и строка начинается с data=password=xxx. Запрос который вы предложили сделать это из примера, так что у меня он не сработает, но проверить через curl идея хорошая, спасибо.

Answer 1

[greensid]

В итоге проблема решилась гениально просто путем изменения кривой части запроса 1500101=account=xxx которая пропадала на 1500101=1500101&account=xxx и к моему удивлению это сработало! Есть только одно предположение, что китайцы которые писали эту апишку решили вместо нормальной пары ключ : значение сделать булевскую переменную из 1500101 и как то через жопу это реализовать. Но это лишь мои догадки. Главное работает и слава богу))