Hello folks,
A broken integration brings me to this forum unfortunatley. Our Moodle site has been operating for about 2 years perfectly but this morning I learned it is not working correctly. This plugin uses an AIM method and nothing has been touched / changed at the site. Our SSL certificate is still good and was issued through godaddy.
Not sure if transaction are working or not, need to wait until the end of day to see how it reconciles. But Basically, learners try to purchase a course and then there is an error, enrolment does not occur.
I am not the only one - other Moodle sites have broke too you can see an active thread of the issue:
http://moodle.org/mod/forum/discuss.php?d=209801
I also documented the trouble in a movie here:
http://www.youtube.com/watch?v=5_p00Ddz1sk&feature=youtu.be
So, I am asking, does anyone know of a change that has happened to AIM method? Security or otherwise that would break an older site? I don't know what to fix , because I don't fully know what the problem is yet.
Thanks for any insight / next step ideas.
John
Solved! Go to Solution.
โ08-27-2012 12:18 PM
UPDATE. A fix has been found and tested for 1.9 moodle sites and you can find it in this thread (same as above):
โ08-29-2012 08:04 AM
Janderso
We've read your report and are taking a closer look. I'll reply here when there is new information available.
Richard
โ08-27-2012 01:15 PM
Hey, I don't know what moodle is but I wanted to let you know that I have a custom AIM integration. The response from the AIM server is usually something like this:
3,1,6,The credit card number is invalid.,,P,0,,,6.37,CC,auth_capture,,,,,,,,,,,,,,,,,,,,,,,,,,EDITEDKAJDFKJADF348UJDKFJDF
But yesterday (at least the first time I noticed it), it started adding two lines before the typical response:
Expires: Thu, 01 Jan 1970 00:00:00^M
^M
3,1,6,The credit card number is invalid.,,P,0,,,6.37,CC,auth_capture,,,,,,,,,,,,,,,,,,,,,,,,,,EDITEDKAJDFKJADF348UJDKFJDF
This is the url that I'm posting my variables to:
secure.authorize.net/gateway/transact.dll
I signed into my authorize.net account and it looks like I'm using version 3 of the api.
Because I have a custom integration, I was easily able to loop through each line of the response and through all of the lines away that do not have a lot of commas (I did it that way in case you ever remove the two new lines in the future).
I would expect that adding those two new lines would cause quite a bit of trouble for people, and what does it mean, anyway?
โ08-27-2012 07:05 PM - edited โ08-27-2012 07:07 PM
I believe the answer to the problem is this:
some simplistic web programs that interact with aim (like mine, admintably), are not understeading the HTTP headers that are received from Authorize.net correctly. Here is how the http headers can be accurately determined and seperated from the message body (which contains the acutal response from authorize.net)
My program, like many others, assumed that the response structure would not change from authorize.net so they simply ignored the first few lines (which were the http headers that were sent originally) so that the program could get to the body of the http response.
Now that an additional HTTP header was added, the program mistakingly assumes that the additional HTTP header is part of the body of the http response.
Although I haven't verified this, my thinking is that two additional http headers were added to the http response and that is why two lines are added to what your moodle program (and my program) thinks is the beginning of the http response.
The better way to handle the http response from authorize.net would be to accurately strip off the http header by looking for the first blank line. From there on out would be the http body.
โ08-28-2012 07:23 AM
Thanks for the ideas jasonh100 . I can verify my test transactions, they were good from yesterday, so the sending to Authorize.net is fine. It's all about the response back that is off. Think I'll put the settings to test mode and see if I can't learn anything more from the POST data being sent.
@Richard - thanks for looking into this.
โ08-28-2012 09:07 AM - edited โ08-28-2012 09:08 AM
We made a change today to the date format for a similar report that may resolve your issue. Please confirm if this change has corrected the problem.
Richard
โ08-28-2012 03:25 PM
I tried a new transaction this morning, but it came back with the same error , moodle does not understand what is being sent back.
I paste the transaction here :
**Please DO NOT REPLY to this message. E-mail support@authorize.net if you have any questions.
========= SECURITY STATEMENT ==========
It is not recommended that you ship product(s) or otherwise grant services relying solely upon this e-mail receipt.
========= GENERAL INFORMATION =========
Merchant : NC Families United, Inc. (872693) Date/Time : 29-Aug-2012 09:19:35 AM
========= ORDER INFORMATION =========
Invoice : 9051
Description : FDA-CFTM
Amount : 45.00 (USD)
Payment Method : Visa
Type : Authorization and Capture
============== RESULTS ==============
Response : This transaction has been approved.
Authorization Code : 081936
Transaction ID : 46072xxxx
Address Verification : Street Address: Match -- First 5 Digits of Zip: Match
==== CUSTOMER BILLING INFORMATION ===
Customer ID : 3
First Name : xxxx
Last Name : xxxxxx
Company :
Address :
City : xxxx
State/Province :
Zip/Postal Code : xxxxx
Country : US
Phone :
Fax :
E-Mail : xxxxxxx
==== CUSTOMER SHIPPING INFORMATION ===
First Name :
Last Name :
Company :
Address :
City :
State/Province :
Zip/Postal Code :
Country :
======= ADDITIONAL INFORMATION ======
Tax :
Duty :
Freight :
Tax Exempt :
PO Number :
โ08-29-2012 06:38 AM - last edited on โ08-29-2012 07:08 AM by RichardH
UPDATE. A fix has been found and tested for 1.9 moodle sites and you can find it in this thread (same as above):
โ08-29-2012 08:04 AM
Pretty old post but still feeling lucky read this discussion, thanks to autohrize community for the nice archive.
โ06-20-2020 11:06 AM
Thank you very much for the nice share buddy, it's the best answer that i have ever seen in this forum.
โ08-24-2020 10:52 AM