Anybody else experiencing a problem with PayPal

[gcamley]

I'm getting the same problem with PayPal however we don't use SSL on our site.

SSL (actually TLS) is used by the scripts on the server to communicate directly with the PayPal server. This is using the PayPal certificate so does not require a certificate on your server.

[feemish]

The paypal script doesnt work with the latest versions of Crypt::SSLeay ?!?

SellerDeck Please help. Paypal Express completely broken. Losing money as we speak.

[prsweeney]

If your host upgraded a Perl module on you, you need to be bugging your host, not Sellerdeck.

[feemish]

If your host upgraded a Perl module on you, you need to be bugging your host, not Sellerdeck.

upgrades are automatically set to the latest stable build, which have all security bugs fixed.
Are you suggesting we never upgrade to the latest build and remain on outdated pearl modules?

If Sellerdeck scripts dont work with the latest stable builds of pearl modules then whose problem do you think it is?

[kraken17]

Bugging Sellerdeck

If your host upgraded a Perl module on you, you need to be bugging your host, not Sellerdeck.

If CPAN release a module update then you should be contacting CPAN. Do you think the CPAN developers care about breaking ACTINIC's websites? Probably not. Easier to ask for an update from SellerDeck.

[prsweeney]

Never said anything of the sort.

However, in order to get yourself back in business, you get your host to roll you back for the time being as you can (hopefully) get that done in a few minutes and you get your store rolling again.

[prsweeney]

kraken17: Well, yeah, an update from CPAN is even more of a pipedream than waiting on a quick fix from Sellerdeck, you're 100% correct with that. Sellerdeck has to do testing, etc.

All I'm saying is that to everyone is to get your store back online, roll back for the time being so your store will at least work until Sellerdeck does release an update. No one is saying to stick with the outdated version....it's certainly not ideal but at least you get your store running.

[kraken17]

Asking CPAN Developer

I have asked this question of the Crypt:SSLeay developer. Hopefully I will get a response.

A change has been made between 0.58 and 0.60 that stops Actinic / SellerDeck from talking to paypal. This is a confirmed problem as the upgrade on my server broke the actinic transfer to paypal, and downgrading it to 0.58 made it work again.

I can also confirm 0.60_01 does not fix the problem either.

Can you tell me if anyone else has reported this fault, and whether you can fix it please?

[kraken17]

PRSWEENEY: Talking to hosting companies is also very complicated. Most of the hosting companies out in the world turn on automatic CPAN updates and do not know how to regress the upgrades if they go wrong.

You get what you pay for nowadays in the hosting world.

[prsweeney]

Good point. I'm spoiled, we use Liquidweb based here in the States, and they are fantastic. They aren't cheap but you shoot them an email and it's done 2 minutes later. Totally recommend them.

[feemish]

Many thanks to Kraken17 for his help in sorting this out.

I presume there needs to be a fix by either Sellerdeck or CPAN asap.

[kraken17]

Contacting CPAN developer

This is the reply from the CPAN developer. I will submit a bug report and see if he can sort it out.

I will keep all followers of this thread updated.


Hello Tim:

I would love to fix it, but I need information on how to diagnose it.

Could you please open a ticket at
http://rt.cpan.org/NoAuth/Bugs.html?Dist=Crypt-SSLeay and provide me
with some more information. I would especially love to see any related
log entries to be able to figure out if the problem is due to LWP
actually checking certificates or due to my changes in the read/write
routines.

And, no, I haven't received any other reports so far, so your report
is the only thing I have to go on.

Thank you.

-- Sinan

[gcamley]

I have a solution that does not involve downgrading the perl modules.

Edit Actinic.pm in the site folder using a text editor such as Notepad
Search for 'sub HTTPS_SendAndReceive'
Now search for 'ssl_socket->read'

you should see

  while ($ssl_socket->read($buf, 1024))
   {
   $sResponse .= $buf;
   }

replace the above with

my ($nBuf) = 1024;
 while ($nBuf == 1024)
  {
  $nBuf = $ssl_socket->read($buf, 1024);
  $sResponse .= $buf;
  }

Save and exit
Update site

The fix is supplied as-is without any warranty i.e. I just wrote it and tested once and it seems to be okay.

Tech comment: It would appear that the perl module no longer reports zero buffer length at end of read loop. There is a possible problem with the way it now works, if the last block of data is 1024 bytes then the same problem may occur unless the perl module still accepts an extra read and returns zero. The code has worked the same way for as long as I can remember (at least 10 years). No idea why it should be changed now.

[kraken17]

Further information

For information. Further information from CPAN developer.

Thank you. Don't worry about the environment variable right now, as
this seems to be related to the read routines. However, for future
reference, see http://stackoverflow.com/questions/3...able-in-apache

I'll try to figure this out as soon as I can, and give you a heads up.

-- Sinan

It is in the CPAN bug reporting area now, and I will be kept upto date about future improvements.

[gcamley]

There is a possible problem with the way it now works, if the last block of data is 1024 bytes then the same problem may occur unless the perl module still accepts an extra read and returns zero.

Tested and found that if the data is the size of the buffer then you cannot determine when you have read all of the data any attempt to read beyond the end of the data causes a script error the same as we have been seeing.

My fix works so long as the response is not 1024 characters. In testing the response was 288 characters so well below the limit.