unserialize() Error in uc_credit_cache()

I presume you're using a credit card payment gateway? Does this happen on all transactions? Are the transactions otherwise successful? What is shown in the payment pane on /admin/store/orders/123 where 123 is the order ID?

Duplicate of the issue raised in #704872: Special characters in billing info (customer name) breaks cc encryption. I suspect that either you're using an older 7.x-3.x-dev or you didn't run update.php when you upgraded. The fix is to use the latest -dev and make sure you run update.php.

Hi longwave and TR.

I've run all updates and I'm running the latest version of ubercart. It's still appearing.
Notice: unserialize() [function.unserialize]: Error at offset 0 of 156 bytes in uc_credit_cache()

Is it possible it's due to a different encryption key on the production versus local machine? I know #704872: Special characters in billing info (customer name) breaks cc encryption fixed this at one point, so I'm trying to see if there is another explanation for this now.

When is this appearing - on which pages? For all orders? Or only for ones you've transferred from a different server (or that might have a different key)?

While I have seen it on the production server (the original bug report from my client), I just tested locally and a big portion of it appears to be a different key between the production and the local server. I pulled down the production key and the errors went away.

The error is found in the following locations:
- /admin/store/orders/18466 (individual admin order view page)
- /store/orders/view
- /admin/store/orders/search

So I'm going to get rid of most of this simply by syncing my keys.

Question, is using the same key from production a security risk?

I'm going to see if there are any remaining areas even with the same key.

Further clarification:
My comments in #6 affected every order. However I was able to get additional errors on my local and production (now using the same ubercart key).

If I go to an order page (e.g. admin/store/orders/18381) I'll see the error while another page (admin/store/orders/18461) does not show it.

I don't see any weird characters/accents. Is there something in particular I would look for?

Thanks for the info, that's enough for me to begin trying to reproduce it here. Special characters were the cause of the other issue, but seems we still need to protect against the unserialize() array not being decrypted for any other reason (such as the key changing).

Fix committed, this also started affecting testbot recently for some reason.

Much appreciated @longwave!