cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Moved behind NGINX now Request.Form keys missing

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;

 

atyler
Member
3 REPLIES 3

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.

akagarwa
Authorize.Net Developer Authorize.Net Developer
Authorize.Net Developer

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.

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...