Jump to content
Sign in to follow this  
Vger

[CONTRIBUTION] Authorize Net AIM module

Recommended Posts

Hello,

 

Sorry to waste your time again, I have a problem that has been covered in this forum before but I just can't fix it.

Trying to run Authorize.net AIM on a shared SSL server.

I have taken care of all that delimited response stuff, I am encoded in cURL and I have used your work-around for the forced cookies (same cookie domain) and yet I can't get round this forced cookies problem.

Does it mean anything that in my sessions configuration folder each option comes up 3 times?

 

Sorry if this is the wrong venue for this discussion, I would appreciate immensely any pointers that you could give me.

 

Thanks

Share this post


Link to post
Share on other sites

If tables are being displayed in your osC admin panel 3 times then this is usually because someone tried multiple installs without dropping the database tables from the previous install. You can access your database via phpMyAdmin, look in all of the pages of the configuration table (quite a few of them), leave in place the first entry you come to but then delete all duplicates.

 

If you use a shared ssl then you cannot use Force Cookie Use. You need a full SSL or no SSL at all - but in that case Authorise Net AIM won't work.

 

Vger

Share this post


Link to post
Share on other sites

Hello all, my apologies if this has been answered. I'm going live with a site tomorrow and didn?t have time to read all 13 pages here. I did a topic search, but didn?t find the answer I was looking for. On to the question.

 

Does this authorize.net payment module allow you to see on the orders admin page (orders.php) or in the individual order detail pages if the credit card transaction has settled successfully? Right now, i don?t see anywhere if an order has settled? it just says: ?Payment Method: Authorize.net - Credit Card? in the little order info box to the right of the orders listed by row on orders.php.

 

Normally it takes a half a day or so to see on authorize.net if a transaction was successfully settled and I?m looking for this type of feedback on the orders page. Obviously it would be beneficial to not have to login to authorize.net, find the transaction and verify that it was settled before I ship products. It would be best if this was possible just in the osc admin system.

 

For example, I have a paypal IPN module installed that says "Payment Status: Completed" underneath a line of text that says ?Payment Method: Paypal? upon a successful transaction through paypal. It does not say ?Completed? if the user backed out or canceled the transaction. That?s the general idea.

 

Thanks a ton,

Nathan

Share this post


Link to post
Share on other sites

Authorize Net AIM is totally different to Pay Pal and cannot be used as a true comparison.

 

Basically the answer is "No, it doesn't do what you'd like it to".

 

Vger

Share this post


Link to post
Share on other sites
Authorize Net AIM is totally different to Pay Pal and cannot be used as a true comparison.

 

Basically the answer is "No, it doesn't do what you'd like it to".

 

Vger

 

Thanks a ton for your quick response Vger! And thank for the great module. I'm going to take a look through the Authorize.net connection documentation for AIM and see if i can find a way to request the transaction status when the order.php page is refreshed or possibly when the order details page is loaded. Of course, if my client is willing to pay for it :-) I'll let you know if I make any progress, sounds like it could be a useful feature if it's possible!

 

Ciao from Madrid!

Nathan

Share this post


Link to post
Share on other sites

I just installed this payment module and it works great, right from the get-go!!!!

 

However, during testing, I've noticed something weird with regards to the error messages displayed. Basically, the error messages for invalid date, invalid number, or invalid card are not displayed properly.

 

The error messages originate in the URL as GET variables, such as:

 

checkout_payment.php?payment_error=authorizenet_aim&error=The+expiry+date+entered+for+the+credit+card+is+invalid.%3Cbr%3EPlease+check+the+date+and+try+again

 

The problem is that when displayed in a browser, the html code for a line break, <br>, is actually shown instead of inserting a line break. As a result, it looks like the following in the browser:

 

Credit Card Error!

The expiry date entered for the credit card is invalid.<br>Please check the date and try again.

 

I took a look at the HTML source code for the page that is created, and you can see that the less-than and greater-than signs are spelled out as '&lt;' and '&gt;'

 

<td class="main" width="100%" valign="top">The expiry date entered for the credit card is invalid.&lt;br&gt;Please check the date and try again.</td>

 

I finally narrowed down the problem to the formatting of the error codes on checkout_payment.php. Around line 194, I changed the following code:

 

<td class="main" width="100%" valign="top"><?php echo tep_output_string_protected($error['error']); ?></td>

 

to:

 

<td class="main" width="100%" valign="top"><?php echo tep_output_string($error['error']); ?></td>

 

As a result, the error messages display properly with line breaks. Has anybody else had this problem?

 

Credit Card Error!

The expiry date entered for the credit card is invalid.

Please check the date and try again.

Share this post


Link to post
Share on other sites

tep-output-string-protected was introduced in the updated version of osCommerce to prevent hack attacks. If you wish to remove it that's fine, but at your own risk. Using tep_output_string_protected should not be a problem provided you are using the updated version of osCommerce - which you should be using anyway because of the security patches.

 

Vger

Share this post


Link to post
Share on other sites
tep-output-string-protected was introduced in the updated version of osCommerce to prevent hack attacks. If you wish to remove it that's fine, but at your own risk. Using tep_output_string_protected should not be a problem provided you are using the updated version of osCommerce - which you should be using anyway because of the security patches.

 

Vger

 

Hi Vger,

 

Thanks for the info. I'm currently using osCommerce 2.2-MS2, which I downloaded a little over a year ago and have been heavily modifying it ever since. So, if there is a newer version with security patches available, integrating the changes might be a little difficult.

 

So if there are pertinent patches that are recommended I integrate, do you have a suggestion as to the easiest way? If there is no easy way, then perhaps I should reinstate tep_output_string_protected and use a string replace to properly format the text?

 

If I have the latest version, any ideas on why I'm running into this problem?

 

Thanks in advance.

 

Mike

Share this post


Link to post
Share on other sites

If you downloaded over a year ago then you're not using the latest version, which was released last November. With the download comes an html file which you can use to supply the updates manually.

 

Vger

Share this post


Link to post
Share on other sites

Hi Vger,

 

Well, I'm still having this problem. And truth is, it has absolutely nothing to do with your Authorize Net AIM module. In fact, the problem occurs using the stock Credit Card payment module.

 

Also, I've done some more testing and the bug seems to be in the base installation of osCommerce. At first, I updated my files with the OsCommerce 051113 update as you suggested, but that didn't fix the problem. I then started with a fresh copy of OsCommerce without any contributions at all, not even Register Globals. The problem still exists.

 

Do you have any ideas why this is happening? I tested it with osCommerce 2.2 Milestone 2 Update 051113 and absolutely NO CONTRIBUTIONS installed. I used the standard Credit Card payment module, entered in the valid testing credit card number during checkout, and entered in an invalid date, such as January 2006. The error message displays as follows:

 

Credit Card Error!

The expiry date entered for the credit card is invalid.<br>Please check the date and try again.

 

I just spent the last couple of hours modifying and testing this problem. I simply can't believe that no one else is experiencing this problem when it happens to me on a clean installation of osCommerce.

 

Thanks for your help. It's much appreciated.

 

Mike

Share this post


Link to post
Share on other sites

Vger,

 

I've done a little more testing, and it appears that the problem lies in the design structure of osCommerce. The code is currently written to not allow any HTML code to be passed through the URL, which is a good thing. But the problem is that the variables for the error messages, which are defined in catalog/includes/languages/english/english.php, have HTML hard-coded into the string. For example:

 

define('TEXT_CCVAL_ERROR_INVALID_DATE', 'The expiry date entered for the credit card is invalid.<br>Please check the date and try again.');
define('TEXT_CCVAL_ERROR_INVALID_NUMBER', 'The credit card number entered is invalid.<br>Please check the number and try again.');
define('TEXT_CCVAL_ERROR_UNKNOWN_CARD', 'The first four digits of the number entered are: %s<br>If that number is correct, we do not accept that type of credit card.<br>If it is wrong, please try again.');

 

As a result, when these variables are passed to the URL as a $_GET variable using urlencode(), then decoded using urldecode(), and finally parsed using tep_output_string_protected(), everything is doing what it's supposed to do properly, including the prevention of HTML code to be passed through the URL. But the problem is that the defined variables have HTML that has been specifically included with the intention to pass through the URL and output on the page correctly.

 

Please run the following script and you'll see what I mean:

 

<?php

 function tep_parse_input_field_data($data, $parse) {
return strtr(trim($data), $parse);
 }

 function tep_output_string($string, $translate = false, $protected = false) {
if ($protected == true) {
  return htmlspecialchars($string);
} else {
  if ($translate == false) {
	return tep_parse_input_field_data($string, array('"' => '"'));
  } else {
	return tep_parse_input_field_data($string, $translate);
  }
}
 }

 function tep_output_string_protected($string) {
return tep_output_string($string, false, true);
 }

define('TEXT_CCVAL_ERROR_INVALID_NUMBER', 'The credit card number entered is invalid.<br>Please check the number and try again.');


echo "<b>TEXT_CCVAL_ERROR_INVALID_NUMBER:</b><br>" . TEXT_CCVAL_ERROR_INVALID_NUMBER;
echo "<br><br>";

$urlencode= urlencode(TEXT_CCVAL_ERROR_INVALID_NUMBER);
echo "<b>\$urlencode:</b><br>" . $urlencode;
echo "<br><br>";

$urldecode= urldecode($urlencode);
echo "<b>\$urldecode:</b><br>" . $urldecode;
echo "<br><br>";

echo "<b>tep_output_string:</b><br>" . tep_output_string($urldecode);
echo "<br><br>";

echo "<b>tep_output_string_protected:</b><br>" . tep_output_string_protected($urldecode);
echo "<br><br>";

?>

 

So the conclusion is that either the defined variables cannot have HTML code in them, tep_output_string() has to be used instead of tep_output_string_protected(), or the variables should be passed using $_POST instead of $_GET.

 

Do you agree? Any other ideas?

 

Mike

Share this post


Link to post
Share on other sites

I am having a problem with my checkout. When a customer goes through the checkout everything is fine until they click the confirm order button on the checkout confirmation page. Instead of the order success page, they logged out and are brought to the login page. Relogging in doesn't work it just refreshes the login page. And there order was never placed.

 

It doesn't seem to happen all the time, since we have still received some orders in, but probably only a 3rd of what we used to. I didn't even know about the problem until a customer called to tell me about it. I just figured it was the season, summers tend to be slow for us. I wonder how many customers I have lost. And I also have no idea how long this has been going on. I've had this contribution since april. It seemed fine at the beginning.

 

I am baffled. I checked everything:

my login/password

my response urls

the direct response settings

my ssl seems fine

 

I even tried switching the ssl to false, but it didn't work, plus I want to use the ssl

 

Any help would be greatly appreciated!!

 

Thank you,

Corinne

Share this post


Link to post
Share on other sites

Vger,

 

I think I found a bug. The install instructions state that the following code needs to be added to checkout_payment.php, but it also needs to be added to checkout_confirmation.php:

 

<script language="JavaScript" type="text/javascript">
<!--hide

function newwindow()
{
window.open('cvv_help.php','jav','width=500,height=550,resizable=no,toolbar=no,menubar=no,status=no');
}
//-->
</SCRIPT>

 

p.s. It would be nice if you could respond to my other posts. I understand if you're busy, though. I'm just saying that it would be nice. Have a good day.

 

Mike

Share this post


Link to post
Share on other sites

You may want to check to see if those people are using AOL as their service provider, and also to check that you have Recreate Session set to false in your osC Admin panel under Configuration --> Sessions. AOL can't keep a session trail to save its life and the use of Recreate Session is just one hurdle too many for it. This doesn't just apply to this payment module, it applies to all.

 

Also check your includes/configure.php file to make sure that the http and https cookie domain settings do not have either http:// or https://in them. These settings are domains and not url's.

 

Vger

 

 

I am having a problem with my checkout. When a customer goes through the checkout everything is fine until they click the confirm order button on the checkout confirmation page. Instead of the order success page, they logged out and are brought to the login page. Relogging in doesn't work it just refreshes the login page. And there order was never placed.

 

It doesn't seem to happen all the time, since we have still received some orders in, but probably only a 3rd of what we used to. I didn't even know about the problem until a customer called to tell me about it. I just figured it was the season, summers tend to be slow for us. I wonder how many customers I have lost. And I also have no idea how long this has been going on. I've had this contribution since april. It seemed fine at the beginning.

 

I am baffled. I checked everything:

my login/password

my response urls

the direct response settings

my ssl seems fine

 

I even tried switching the ssl to false, but it didn't work, plus I want to use the ssl

 

Any help would be greatly appreciated!!

 

Thank you,

Corinne

Share this post


Link to post
Share on other sites

Its' not a bug. If you want to have a pop-up window on more then one page then that's entirely up to you, but checkout_payment is the logical choice to put a pop-up giving advice about Card Verification. Why you'd want it on one page ad then have it again on the next page is not something I understand.

 

Your other posts contain comments already answered elsewhere in this thread.

 

Vger

Vger,

 

I think I found a bug. The install instructions state that the following code needs to be added to checkout_payment.php, but it also needs to be added to checkout_confirmation.php:

 

<script language="JavaScript" type="text/javascript">
<!--hide

function newwindow()
{
window.open('cvv_help.php','jav','width=500,height=550,resizable=no,toolbar=no,menubar=no,status=no');
}
//-->
</SCRIPT>

 

p.s. It would be nice if you could respond to my other posts. I understand if you're busy, though. I'm just saying that it would be nice. Have a good day.

 

Mike

Share this post


Link to post
Share on other sites

Vger,

 

I just checked all those things. My cookie settings are not urls, my session is set at false, and its not the aol thing, because I do not have AOL and when I create an account myself it still doesn't work.

 

Any ideas?

 

Thanks,

Corinne

 

 

You may want to check to see if those people are using AOL as their service provider, and also to check that you have Recreate Session set to false in your osC Admin panel under Configuration --> Sessions. AOL can't keep a session trail to save its life and the use of Recreate Session is just one hurdle too many for it. This doesn't just apply to this payment module, it applies to all.

 

Also check your includes/configure.php file to make sure that the http and https cookie domain settings do not have either http:// or https://in them. These settings are domains and not url's.

 

Vger

Share this post


Link to post
Share on other sites
my ssl seems fine

 

We'd need to be sure that your ssl is actually fine, and if cURL is compiled into php. For the first, can you post a URL to your website. For the second - is your site hosted on a Windows server?

 

Vger

Share this post


Link to post
Share on other sites

Vger,

 

My website is www.aurabackdrops.com.

 

It is not hosted on a windows server.

 

Corinne

 

We'd need to be sure that your ssl is actually fine, and if cURL is compiled into php. For the first, can you post a URL to your website. For the second - is your site hosted on a Windows server?

 

Vger

Share this post


Link to post
Share on other sites

Problem solved (at least for A Net) - because your ssl cert (shared) is not properly set up.

 

If you go to any https page and do a 'View Source' in your browser then you'll see this:

<base href="http://aurabackdrops.com/">

 

it should be:

<base href="https://webhosted.com/~auraback/">

 

You don't get any padlock in the browser to show you are on an https page, and your pathway to the shared ssl has an extra '/' in it e.g.

https://web-hosted.com/~auraback//login.php

 

You need to sort out your includes/configure.php file - but there may also be other ssl problems.

 

Vger

Share this post


Link to post
Share on other sites

Vger,

 

How do I change the base href? What file or files Do I need to change.

 

I apologize I am fairly new to php.

 

Here is part of my configure file. What do I need to change?

 

define('HTTP_SERVER', 'http://aurabackdrops.com'); // eg, http://localhost - should not be empty for productive servers

define('HTTPS_SERVER', 'https://web-hosted.com/~auraback/'); // eg, https://localhost - should not be empty for productive servers

define('ENABLE_SSL', true); // secure webserver for checkout procedure?

define('HTTP_COOKIE_aurabackdrops.com', 'aurabackdrops.com');

define('HTTPS_COOKIE_aurabackdrops.com', 'web-hosted.com/~auraback/');

define('HTTP_COOKIE_PATH', '/');

define('HTTPS_COOKIE_PATH', '/');

define('DIR_WS_HTTP_CATALOG', '/');

define('DIR_WS_HTTPS_CATALOG', '/');

 

Thank you so much for all your help.

Corinne

 

quote name='Vger' date='Jul 28 2006, 11:33 AM' post='905088']

Problem solved (at least for A Net) - because your ssl cert (shared) is not properly set up.

 

If you go to any https page and do a 'View Source' in your browser then you'll see this:

<base href="http://aurabackdrops.com/">

 

it should be:

<base href="https://webhosted.com/~auraback/">

 

You don't get any padlock in the browser to show you are on an https page, and your pathway to the shared ssl has an extra '/' in it e.g.

https://web-hosted.com/~auraback//login.php

 

You need to sort out your includes/configure.php file - but there may also be other ssl problems.

 

Vger

Share this post


Link to post
Share on other sites
Its' not a bug. If you want to have a pop-up window on more then one page then that's entirely up to you, but checkout_payment is the logical choice to put a pop-up giving advice about Card Verification. Why you'd want it on one page ad then have it again on the next page is not something I understand.

 

Thanks for the reply.

 

Your other posts contain comments already answered elsewhere in this thread.

 

I have to respectfully disagree unless you're talking about an earlier discussion before I brought up the subject. If that's the case, then I'll have to re-read all 15 pages again. Perhaps I missed it.

 

If that's not what you meant, then this is your first response to my new discoveries. To reiterate, I heeded your advice with regards to updating to the newest version, and that didn't fix the problem. I then went to a raw installation of osCommerce without any contributions and the problem still existed. I even went a step further and picked a handful of random live shops, created an account, and proceeded to make my way through the checkout process. I then specifically entered in invalid data for the credit card information, and in every case, the problem mimicked mine exactly. So this tells me that the problem is not something specific to me, but with osCommerce.

Edited by zoeticlight

Share this post


Link to post
Share on other sites
define('HTTPS_SERVER', 'https://web-hosted.com/~auraback');

define('HTTP_COOKIE_DOMAIN', 'aurabackdrops.com');

define('HTTPS_COOKIE_DOMAIN', 'web-hosted.com/~auraback');

 

If you still don't get the padlock then you need to look for posts about 1and1 and problems with their shared ssl settings.

 

Vger

Edited by Vger

Share this post


Link to post
Share on other sites
Problem solved (at least for A Net) - because your ssl cert (shared) is not properly set up.

 

If you go to any https page and do a 'View Source' in your browser then you'll see this:

<base href="http://aurabackdrops.com/">

 

it should be:

<base href="https://webhosted.com/~auraback/">

 

You don't get any padlock in the browser to show you are on an https page, and your pathway to the shared ssl has an extra '/' in it e.g.

https://web-hosted.com/~auraback//login.php

 

You need to sort out your includes/configure.php file - but there may also be other ssl problems.

 

Vger

 

Hi Rhea, this exactly what I was talking about on the other post, with respect to set only the server name and then to set the subsequent paths to the HTTPS_COOKIE_PATH and DIR_WS_HTTPS_CATALOG. So once you set:

 

define('HTTPS_SERVER', 'https://web-hosted.com');

define('HTTPS_COOKIE_DOMAIN', 'web-hosted.com');

define('HTTPS_COOKIE_PATH', '/~auraback/');

define('DIR_WS_HTTPS_CATALOG', '/~auraback/');

 

then you do not need to change the baseref manually in the files. It's easier.

Share this post


Link to post
Share on other sites

Hi Mark, I know what you are saying, but in my opinion that isn't the correct way to set up osCommerce to handle a shared ssl, and even if the poster does use what you've posted I don't think it will solve the problem.

 

I think they need to look at Post 48 here:

http://forums.oscommerce.com/index.php?sho...mp;#entry508060

 

That's why I think they don't get the padlock - even when the correct pathway is used.

 

Vger

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×