We have an application using the Authorize.net dll and has been working fine untill we moved servers behind NGINX reverse proxy. The form keys comming back to the application's handler appears to now be removed.
I valadated the call back is hitting the page handling the call back. I am not an expert with NGINX, the Devops says it should work just fine. The following are the location settings:
proxy_pass $legacy_upstream; proxy_set_header Host $http_host; proxy_set_header Connection keep-alive; proxy_set_header Upgrade $http_upgrade; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; # support huge file responses client_max_body_size 0; client_body_in_file_only clean;
12-13-2017 06:25 AM
Can we have some more information regarding the request that is confirmed to be hitting the page handling the call back? You could try capturing the request and logging it.
Something that might be helpful:
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_http_version
recommend setting the proxy_http_version as 1.1 for keep-alive connections.
12-14-2017 07:24 PM
Thanks
We know it is hitting the hadler page because we have code writing to the database. We tried forcing the relay page to be an HTTPS to ensure we were not sending on HTTP and we get the same result.
We will review the document to see if we missed anything.
12-20-2017 10:34 AM
Interesting that the headers are not passed by NGINX. We placed a page to gather header information coing into the site. The code for sending the relay page was basing the sting off the server protocal - Since we changed the server to be HTTP, this was picking up http://blah/blah... which was being redirected, and appears to be stripping header info on the redirect.
We st the relay to a prefix of "https://". This now appears to work.
Thanks for th information and recommendation...
12-21-2017 03:48 AM