@greensid

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

Пытаюсь организовать доступ к 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? В какую сторону копать вообще?

Заранее благодарен за помощь!
  • Вопрос задан
  • 73 просмотра
Пригласить эксперта
Ответы на вопрос 1
@greensid Автор вопроса
В итоге проблема решилась гениально просто путем изменения кривой части запроса 1500101=account=xxx которая пропадала на 1500101=1500101&account=xxx и к моему удивлению это сработало! Есть только одно предположение, что китайцы которые писали эту апишку решили вместо нормальной пары ключ : значение сделать булевскую переменную из 1500101 и как то через жопу это реализовать. Но это лишь мои догадки. Главное работает и слава богу))
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы