Authorize.net DPM - выполнять обработку на стороне сервера в сервлете, а не в jsp

Question

В настоящее время я работаю с тестовой учетной записью на Authorize.net и использую форму Direct Post Method для отправки транзакций непосредственно на их шлюз без дополнительной обработки на стороне сервера с моей стороны. Мое приложение представляет собой базовое jsp-веб-приложение, расположенное поверх Apache Tomcat 7.

В соответствии с инструкциями, приведенными в их Руководстве по быстрому запуску Java, я настроил 3 файла для: 1) ввода пользовательского ввода, 2) передачи ответа и 3) обработки и отображения вывода.

По правде говоря, мне не нужно отображать вывод для пользователя. Вместо этого я хотел бы тщательно обработать ответ, который посылает мне Authorize.net. Пример кода, который они предоставляют, явно объясняет это в файле relay_response.jsp:

String receiptPageUrl = "http://MERCHANT_HOST/order_receipt.jsp";
...
net.authorize.sim.Result result = net.authorize.sim.Result.createResult(apiLoginId,
 MD5HashKey, request.getParameterMap());
// perform Java server side processing...
// ...
// build receipt url buffer
StringBuffer receiptUrlBuffer = new StringBuffer(receiptPageUrl);
...
...
document.location = "<%=receiptUrlBuffer.toString()%>";

Тем не менее, похоже, что они хотят, чтобы я выполнил обработку в jsp, в то время как я бы предпочел выполнить эту работу на бэкэнде, используя сервлет Java. Я попытался сделать это, используя 2 метода, ни один из которых не работает так, как я хочу.

Попытка 1) Я заменил тег order_receipt.jsp на URL другого jsp, который впоследствии отправляет форму сервлету, передавая все параметры запроса.

String receiptPageUrl = "http://<my_server's_ip_address>/another.jsp";

Проблема с этим подходом состоит в том, что при первоначальной пересылке из relay_response.jsp все параметры передаются через GET и появляются в URL, что я не могу допустить.

Попытка 2) Вместо того, чтобы пересылать результаты в другой jsp, я создал форму прямо в relay_response.jsp и попытался отправить форму с результатами, переданными в качестве параметра запроса.

<form id='myform' method='post' action="servlet_action" accept-charset='UTF-8'>
  <input id='params' type='hidden' name='params' value='<%= paramsMap %>'/>
</form>
<script type="text/javascript">
  document.getElementById("myform").submit();
</script>

Проблема здесь в том, что, хотя браузер отображает мой файл relay_response.jsp, значением document.location.hostname является test.authorize.net, поэтому он не распознает мои действия, поскольку они находятся на моем сервере, а не на authorize.net. сервер.

В качестве альтернативы я попытался установить действие в форме, чтобы оно было полным URL-адресом действия моего сервера и сервлета:

<form id='myform' method='post' action="http://<my_server's_ip_address>/webapp/servlet_action" accept-charset='UTF-8'>

Но я получаю предупреждение (по крайней мере, в Firefox) о том, что данные не передаются по безопасному соединению: "Хотя эта страница зашифрована, введенная вами информация должна передаваться через незашифрованное соединение и может быть легко прочитана третий участник."

Как я могу передать результаты транзакции из relay_response.jsp в мой Java-сервлет, не раскрывая параметры, передаваемые пользователю? Должен ли я использовать https? И почему document.location.host указывает на authorize.net, а не на мой relay_response.jsp?

Спасибо!

Answer 1

Друг предложил 2 решения для первоначального вопроса, который я разместил, одно из которых я проверил.

Решение 1. Просто перенаправьте исходную форму на сервлет, а не на relay_response.jsp. Затем сервлет может перенаправить на другой jsp как соответствующий. Я подтвердил, что это работает с Authorize.net DPM.

Решение 2. Внутри скриптлета в relay_response.jsp вызовите класс Java, который фактически обрабатывает логику. Вам не нужно открывать или писать какой-либо код Java внутри скриптлета, а просто вызывать класс и вызывать несколько методов. Вы можете передать карту параметров ответа в качестве аргумента методу. Я полагаю, что класс, который вы вызываете, мог бы быть даже правильным сервлетом, хотя смешивать их, возможно, не очень хорошая форма.