URL: http://www.uburst.com/cgi-bin/dcforum/dcboard.cgi
Forum: ushp_general_purpose
Thread Number: 426
[ Go back to previous page ]

Original Message
"I need tech support to reply to my post "

Posted by Sommay [info@blackchips.com] on at 09:41 PM
I need tech support to reply to my post at the following link:
http://www.uburst.com/dcforum/ushp_general_purpose/360.html

Table of contents

Messages in this discussion
"Tech Support RE: IP Address "
Posted by Microburst Support [support@uburst.com] on at 09:57 AM
The REMOTE_ADDR is the IP address of the remote host making the request. Typically, this will be user's browser making the request, so the REMOTE_ADDR will be set to the IP address of the user... or rather the IP address of the user's connection through his/her Internet Service Provider. In cases where the request comes from another CGI script/application that redirects or POSTs the request, then the REMOTE_ADDR would be set to that of the other CGI script/application (This is often the case of external payment processing systems redirecting or POSTing their approved/denied response back to the uShop CGI script.)
What may have to be done in order to get the customer's $REMOTE_ADDR is to obtain and save the customer's $REMOTE_ADDR before the credit card transaction script is run.
1) Obtain the customer's REMOTE_ADDR before transferring to your credit card transaction script. The REMOTE_ADDR can be obtained with the following line of Perl code:
$REMOTE_ADDR = $ENV{'REMOTE_ADDR'};
2) Save the $REMOTE_ADDR in a temporary file or, if the credit card transaction script will pass variables through for you, pass it as a parameter to your credit card transaction script.
3) In uShop's "complete_order" subroutine, re-obtain the $REMOTE_ADDR from whatever method use used to save it in step 2 above.

"Step by Step please."
Posted by Sommay [info@blackchips.com] on at 06:22 PM
Thank you for your reply but can you please provide me a detail step by step on how to integrate your step 1,2 and 3.

I understand what you're saying but I'm not sure where to start


"step by step"
Posted by Microburst Support Team [support@uburst.com] on at 09:48 AM
As this is not a simple coding effort, it involves customization work which you can purchase from Microburst Technologies.

Send a request for a customization quote to support@uburst.com along with your change requirements.


"Step by Step please."
Posted by Sommay [info@blackchips.com] on at 02:26 PM
If you look at my post http://www.uburst.com/dcforum/ushp_general_purpose/360.html you would see I have done alot of customization already. Get me start somewhere here! I shouldn't have to purchase it!

Is Bill Weiner around?


"RE: Step by Step please."
Posted by Bill Weiner on at 06:41 AM
Since you are using the uShop - Authorize.Net SIM interface, I can say that uShop already obtains the customer's IP address (using $ENV{'REMOTE_ADDR'}) and passes it to Authorize.Net (via Authorize.Net's x_customer_ip) parameter. So you might want to first check on Authorize.Net's side of things that the Customer's IP is being recorded there in the first place. (ie. look at the details of the transaction and see what is says the customer's IP address is.) If it looks ok at that point, then we can see about adding a line like this to your ushop.pl script:

$receipt_text .= $form_text{'x_customer_ip'};

But if it does not look ok, then the problem could just be that your server is not obtaining/setting the REMOTE_ADDR environment variable and/or your server doing some sort of RELAY that is causing the REMOTE_ADDR to always be set to the same value.