переменные после обратного вызова "исчезают"

#codeigniter #curl #callback

#codeigniter #curl #обратный вызов

Вопрос:

чувак, я в тупике, и ты, вероятно, не сможешь помочь, но, возможно, если я расскажу об этом здесь:

Это пользовательская CMS CodeIgniter.

Я устраняю неполадки в пользовательской cms, которую написал кто-то другой; в частности, один из платежных шлюзов (библиотека типа HSBC, похожая на PayPal или тому подобное, но использующая Curl)

Он имеет функцию обратного вызова с сайта банка, возвращающую набор переменных $ _POST.

ПРОБЛЕМА: переменная $ _POST недоступна из контроллера приложения (я вижу, что они возвращаются с помощью HttpFox)

Я МОГУ:

1) вернитесь на страницу, отличную от app .php, и print_r ($ _POST) (т. Е. URL обратного вызова — это просто еще одна страница на моем сервере, за пределами CI)

2) отправьте форму из приложения или из приложения на подозрительный контроллер и без проблем print_r ($ _POST) (т. Е. Этот контроллер / приложение МОЖЕТ получать обычное сообщение)

Итак, попытка прочитать результаты $ _POST из самого обратного вызова — это то, что терпит неудачу.

Есть идеи, что проверить или как это отследить? Очевидно, что где-то есть какая-то настройка, возможно, с помощью Curl, но я в недоумении. Рад опубликовать код / дополнительную информацию, как только я выясню, в каком направлении двигаться

TIA,

джефф

Ответ №1:

Получение переменных POST в CodeIgniter достигается через класс ввода. В документации указано, что все суперглобальные переменные уничтожены.

Затем получение содержимого $_POST[‘something’] должно выполняться:

 $something = $this->input->post('something');

1. почему люди продолжают мне это говорить? «2) отправьте форму из приложения или из приложения на подозрительный контроллер и без проблем print_r ($ _POST) (т. Е. Этот контроллер / приложение МОЖЕТ получать обычное сообщение)» $ _POST отлично работает в CodeIgniter; $this-> input-> post() рекомендуется, поскольку это позволяет вам выполнять очистку. Я использую $_POST здесь только для отладки

2. Используете ли вы пользовательский родительский контроллер?

3. это так, но я также попробовал сразу с CI_Controller, мои подозреваемые: 1) что-то с моим CURL 2) не знаю .. поскольку я могу отправлять сообщения непосредственно из своей собственной фиктивной формы, просто не считывая данные обратного вызова

4. Не могли бы вы обновить свой вопрос своим URL-адресом обратного вызова и кодом контроллера обратного вызова?

Ответ №2:

хорошо, немного более пристальное наблюдение окончательно отследило это:

у предыдущего разработчика был .htaccess, чтобы сначала добавить завершающую косую черту, а затем удалить .index.php ?

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

Спасибо