COWOA (for ZC v1.5.x)

[lat9]

To make COWOA case-insensitive for the "no-account" customers, you could simply edit the header_php.php for the orders_status page and wrap strtolower() around both variables in the comparison done in:

  if (isset($_POST['query_email_address']) && $customer_info->fields['customers_email_address'] != $_POST['query_email_address']) {

That might not take into account the use of multibyte characters in your email addresses, but if that's a rarity for your typical customer then it might be moot.

The standard Zen Cart login is case-insensitive ... because the database is case-insensitive -- that's with the _ci is on the end of the database collation. A collation of utf8_general_ci indicates that database compares are to be case-insensitive.

That said, in a standard Zen Cart installation, if you create an account using the email address of [email protected] there is no problem on the login page using [email protected] ... because the comparison is done via the database lookup. Changing the order_status page's header_php.php starting at line 24 to the following uses the database comparisons and achieves the same functionality as DrByte's solution:

  $customer_info_query = "SELECT customers_email_address, customers_id
                          FROM   " . TABLE_ORDERS . "
                          WHERE  orders_id = :ordersID
                          AND    customers_email_address = :emailAddress";

  $customer_info_query = $db->bindVars($customer_info_query, ':ordersID', $_POST['order_id'], 'integer');
  $customer_info_query = $db->bindVars($customer_info_query, ':emailAddress', $_POST['query_email_address'], 'string');
  $customer_info = $db->Execute($customer_info_query);

  if ($customer_info->EOF) {
    $errorNoMatch=TRUE;
  } else {
...

P.S. Off-subject, but when I did a fresh install of COWOA on a fresh install of Zen Cart 1.5.1, the define TEXT_CHECKOUT_LOGOFF_CUSTOMER appears to be missing from the orders_status page.

[HeathenMagic]

Hello there,
Just installed this mod, it works very well. I just have two design issues that may be specific to me, that I have been tearing my out trying to figure out lol.

1. If you use Checkout Without Account, the Newsletter Subscribe area does not have a tickbox, it just forces html or text instead of being optional. Normal create account is fine

2. Checkout Payment - step 2. The discount coupon, reward and payment method boxes appear without white background, above the Order Steps and order total boxes, which has the Continue Checkout button above the Order Steps. The next page has the same issue also, but the Checkout Shipping page looks perfect.

It is all very strange. I completely gutted a FEAC checkout install, SQL aswell. Pretty sure I have removed all traces of it, and overwritten checkout page files first from stock 1.51 Zencart files. Then I copied over the COWOA files on top, plus SQL. All enabled from admin. The only thing I have is Ceon URI mapping, but I have removed the URis now.

Any help is greatly appreciated, many thanks in advance

[Limitless]

The standard Zen Cart login is case-insensitive ... because the database is case-insensitive -- that's with the _ci is on the end of the database collation. A collation of utf8_general_ci indicates that database compares are to be case-insensitive.

That said, in a standard Zen Cart installation, if you create an account using the email address of [email protected] there is no problem on the login page using [email protected] ... because the comparison is done via the database lookup. Changing the order_status page's header_php.php starting at line 24 to the following uses the database comparisons and achieves the same functionality as DrByte's solution:

  $customer_info_query = "SELECT customers_email_address, customers_id
                          FROM   " . TABLE_ORDERS . "
                          WHERE  orders_id = :ordersID
                          AND    customers_email_address = :emailAddress";

  $customer_info_query = $db->bindVars($customer_info_query, ':ordersID', $_POST['order_id'], 'integer');
  $customer_info_query = $db->bindVars($customer_info_query, ':emailAddress', $_POST['query_email_address'], 'string');
  $customer_info = $db->Execute($customer_info_query);

  if ($customer_info->EOF) {
    $errorNoMatch=TRUE;
  } else {
...

P.S. Off-subject, but when I did a fresh install of COWOA on a fresh install of Zen Cart 1.5.1, the define TEXT_CHECKOUT_LOGOFF_CUSTOMER appears to be missing from the orders_status page.

This fix works perfectly!

Thank you!

[DivaVocals]

Not to continue this, but what you refer to as an 'email address login' is really a UPN, whether that is really the 'email address' of the user, is irregardless. And 'checking' case sensitivity and HAVING 5 users with [email protected], [email protected], [email protected] and [email protected] is ridiculous and those are NOT email addresses as they would all have mail delivered to the same place. Your security by obscurity just fell apart.

Within ~applications~ on a corporate network, sure, ~programmers~ can require case sensitivity on user names, but if you display that logins MUST BE IN CAPS on the login page, that sort of defeats the argument.

And this IS the place to talk about this, while ZenCart does not use email addresses for logins, my inquiry was related to order status checking with COWOA accounts and that does require using an email address along with order number to verify identity.

*nix systems and their derivatives have case sensitive user names. Windows, Netware and other LDAP based systems do not.

Again you have clearly misunderstand what I have stated previously.. So let me state this..

I am WELL AWARE that e-mail addresses in an e-mail system used to send and receive e-mail are NOT case sensitive.. Let me further be clear that I am also not talking abut LDAP, Windows, or Netware systems either as that is a completely different discussion.. Zen Cart is NONE of these kinds of systems.. (apples and oranges)

So now we are back to a software system which happens to use e-mail addresses as the user login. Not an e-mail address tied to any e-mail, Windows, Netware or LDAP server. Rather a VALUE for a user login that is stored in a database which happens to be an e-mail address.. Therefore as I stated originally, user logins in a software system CAN BE case sensitive and this is usually done for security purposes much like the reason that passwords are also case sensitive. lat9 provided the explanation why this is so, and it is not something that COWOA does that makes customer logins case sensistive. It its a part of core Zen Cart functionality. lat9 and DrByte also have pointed out that there is a way to modify this behavior with code. I personally like the extra measure of security that case sensitivity offers. You do not agree clearly.. Different strokes..

[DrByte]

Is this thread gonna continue arguing back and forth about whether emails should be case sensitive?

If so, start another thread for that. Everyone using COWOA doesn't need to be blasted with email notices about your differences of opinions.


Zen Cart should (and has always intended to) treat email addresses as case-insensitive. It is rare when it does not.
The suggestions proposed above show how to make that happen with COWOA's code as well, and I suspect the next update to COWOA will incorporate one of these approaches.
The core of Zen Cart will certainly treat emails as case-insensitive whenever guest-checkout is incorporated.

[countrycharm]

Is this thread gonna continue arguing back and forth about whether emails should be case sensitive?

If so, start another thread for that. Everyone using COWOA doesn't need to be blasted with email notices about your differences of opinions.

Zen Cart should (and has always intended to) treat email addresses as case-insensitive. It is rare when it does not.
The suggestions proposed above show how to make that happen with COWOA's code as well, and I suspect the next update to COWOA will incorporate one of these approaches.
The core of Zen Cart will certainly treat emails as case-insensitive whenever guest-checkout is incorporated.

I did have a thread I started talking about whether emails should be case sensitive or case insensitive. You could have move all this extra post to it if it still existed.

[DrByte]

I was kinda suggesting that the point has already been flogged to death and doesn't need more discussion.

[countrycharm]

Hello there,
Just installed this mod, it works very well. I just have two design issues that may be specific to me, that I have been tearing my out trying to figure out lol.

1. If you use Checkout Without Account, the Newsletter Subscribe area does not have a tickbox, it just forces html or text instead of being optional. Normal create account is fine

2. Checkout Payment - step 2. The discount coupon, reward and payment method boxes appear without white background, above the Order Steps and order total boxes, which has the Continue Checkout button above the Order Steps. The next page has the same issue also, but the Checkout Shipping page looks perfect.

It is all very strange. I completely gutted a FEAC checkout install, SQL aswell. Pretty sure I have removed all traces of it, and overwritten checkout page files first from stock 1.51 Zencart files. Then I copied over the COWOA files on top, plus SQL. All enabled from admin. The only thing I have is Ceon URI mapping, but I have removed the URis now.

Any help is greatly appreciated, many thanks in advance

I will look into why the Newsletter Subscribe area does not have a tick-box. I haven't even notice that before now.

Everything else you are describing is because you didn't uninstall FEC right or still have some files fron FEC checkout installed somewhere. Check to make sure you installed Cowoa right.

You can look at the pictures I posted below to show what you are describing is not possible if you installed Cowoa right.

[countrycharm]

I was kinda suggesting that the point has already been flogged to death and doesn't need more discussion.

.......Nods in agreement........

[DivaVocals]

I was kinda suggesting that the point has already been flogged to death and doesn't need more discussion.

.......Nods in agreement........

Agreed.. I can assure you, I was done with my last post on this topic.. DrByte.. you have my apologies..