Ubercart

Very interesting... sorry for the trouble. I wonder if I can use utf8_decode() to sanitize fields prior to encryption.

For us I think it'd be a rare thing, but you never know when someone will use a character like that in their last name. And for European cart merchants especially, it'll affect them more, I'm sure.

If encoding or decoding to utf8 would work. I'm wondering how the pathauto module does it? I think it might actually use the same premise to take non-standard chars and convert them to their standard equivalent.

Pathauto was the first module I thought of, too. I'll try to check it out and work that into the encryption class...

Transliteration is the keyword, see install.txt. The complete i18n-ascii-full.txt has 470kb.
Would be nice if all the pathauto users who already configured i18n-ascii.txt could recycle it for cc encrytion.

Heh.. we just had another person email us with this issue. I guess we have more Swedish customers than I thought! Any update on this? (No rush, really - just checking.)

I'm gonna need some help on this one... I'd love to have a simple solution for core, even if it just means stripping out illegitimate characters. There's a transliteration module available at http://drupal.org/project/transliteration that we can maybe hook into further. Anyone wanna take this on?

As soon as I get some free time I can contribute. This week is Comic-Con, and we have a booth there, so this week was gone before it even started But it is something we need since we have international customers. I wonder how (if?) anyone in Germany or Sweden has approached or dealt with this issue?

The odd thing is Drupal itself, without that module, seems to have disagreed with the character as well. The name Björn (when used in a username) is created as Bj-rn. I will look into installing that module as a counter to that issue as well..

Actually, I just got it to work.

- Installed Tranlisteration module.
- Went into uc_credit.module. Everywhere there was mention of check_plain($_POST['cc_owner']) I replaced it with check_plain(transliteration_get($_POST['cc_owner'])).

I was able to test this by creating a test order, and just editing the Order Details, Payment method (Credit Card).

Originally:
- Add a user "Test Test" with all card details. Saves fine.
- Edit details of Card Owner to say "Björn Test" and re-save.
- Reload order details, all of the Credit Card data is gone from the order.

After I edited the .module:
- Edit details of Card Owner to say "Björn Test" and saved.
- Reloaded order. Card Owner now shows as "Bjorn Test" (note the transliterated "o").
- All card data is visible in the order.

I think this would be enough to satisfy this issue? What do you think? The entire process only took a few minutes but I haven't done any thorough testing. Initial results are positive, though. My only concern is that this would add another module dependency. Or you could just add switches in, as per the README doc:

So maybe not a dependency per se, but a recommendation for any stores who might be selling outside of the US.

Yeah, I think I like this idea... I just have to remember to document it.

A lot of people won't even need to collect CC names, so for most people it's quite likely they'll never be attempting to encrypt unsupported characters anyways. Thanks for lending a hand!

When you say they "won't need to collect CC names" .. is that an option? I hadn't even thought to look - can I remove the Card Owner field? Will that field get replaced by the "Billing Information" names? Or can it just be removed without any issues? I'll look at our authorize.net settings and see if we're requiring a name on the cards. If that's the case then maybe I'll just do away with that field altogether...

Yeah, it's totally an option in the CC settings. Our company uses CyberSource and I don't think we ever enter names. I'm honestly not even sure which of the payment modules accommodate the CC name and which just use the billing name.

After consulting with our accounting department, we do need to keep the Card Owner field - so I think leveraging the Transliteration module would be a good idea. I honestly have never seen a store that did not ask for a separate Card Owner, or at least only asked for the Billing Address (no names) and then used the Card Owner field as the Billing information name.

So I think that leaving them as-is should be the way to go. If the Billing customer info isn't getting encrypted then there's no need to transliterate it; but any text strings that have the potential to break encryption should be.

I saw that this was updated to "fixed" - what did the solution end up being?

Not sure.. cha0s made that change, but I think he might have just been rolling through the tracker cleaning up old issues. I'll ping him on this one.

This was not fixed in the ver i bzred yesterday.

Had to manually patch uc_credit.module with transliteration_get

I have the same issue and I'm not sure how or what to do here..
I'm localizing the cart to Hebrew and the card holder name must be in hebrew.

Does anyone here have an idea how to get past the warning msg?

One of the fundamental flaws of the encryption scheme chosen by Ubercart is the fact that it is limited to only "all 95 printable characters from the ASCII character set EXCEPT single quote, double and backslash". In particular, it can't handle non-ASCII Latin characters, so ironically Ubercart can't even encrypt Ãœbercart. And it certainly can't handle the entire Unicode set, even in UTF-8 form, so Hebrew or Arabic are not possible. The only real solution is to replace the flawed encryption scheme with a more robust and capable one.

any sollution on this?

Just ran into this problem at my site as well, using Ubercart 5.x-1.9

i also had this problem, and found the culprit in the Payment Settings area (not caused by any odd last names)

In the Credit Card Settings (Choose Payment Methods >> Payment Settings >> Credit Card Settings), and look to the Card Type Select Box Options -switch this field to PLAIN TEXT, and get rid of all the HTML tags, and save.

Problem solved!

@dmsky: Your post has nothing to do with this issue. Your image shows you have CKEditor enabled for the credit card type textarea, and it is CKEditor that is adding the paragraph tags. Regardless, that doesn't affect encryption at all.

This issue is being addressed in the Ubercart issue queue at http://drupal.org/project/issues/ubercart

Issue addressed at http://drupal.org/node/704872 with patches available.