COWOA (for ZC v1.5.x)

robbie269:

I cannot find where I can comment in GITHUB sorry.
Click the "Issues" tab, and if your issue isn't in the list of open issues (or in the list of closed issues, by clicking the Closed tab), then click the New Issue button to create one.

robbie269:

Testing the new COWOA for v1.5.5 today. I cannot find where I can comment in GITHUB sorry.
One thing I did notice is that the sidebox off option during checkout includes the Logged of page. When I logoff the confirmation page fills half the screen and the rest is white. It has a "broken" look about it and I think the sideboxes should be on for the log off confirmation page as who cares if they go back to browsing.

If you'd prefer the logoff page with sideboxes, edit your \includes\templates\YOUR_TEMPLATE\common\tpl_main_page.php by removing logoff from the following list:

if (COWOA_SIDEBOX_OFF == 'true') {  
if (in_array($current_page_base,explode(",",'no_account,create_account,account,account_password,account_edit,address_book,account_history_info,account_newsletters,account_notifications,account_history,login,logoff,checkout_shipping,checkout_shipping_address,checkout_payment,checkout_payment_address,checkout_confirmation,checkout_process,shopping_cart,address_book_process')) ) {
    $flag_disable_right = true;
    $flag_disable_left = true;
  }
}

jeking:

If you'd prefer the logoff page with sideboxes, edit your \includes\templates\YOUR_TEMPLATE\common\tpl_main_page.php by removing logoff from the following list:

if (COWOA_SIDEBOX_OFF == 'true') {
if (in_array($current_page_base,explode(",",'no_account,create_account,account,account_password,account_edit,address_book,account_history_info,account_newsletters,account_notifications,account_history,login,logoff,checkout_shipping,checkout_shipping_address,checkout_payment,checkout_payment_address,checkout_confirmation,checkout_process,shopping_cart,address_book_process')) ) {
$flag_disable_right = true;
$flag_disable_left = true;
}
}

Which is exactly what I was going to state as well..

ianhg:

Thanks Guys for the links and speedy reply. Happy to test but which GitHub link is the best option?
Thanks.

BIG THANKS really goes to jeking who made up for my lack of free time..

I thought we added observers to COWOA! Maybe I missed something...

I've been busy converting mine which is not to bad, has some new interesting code in 1.5.5 that should make things interesting.. With the way COWOA is setup now, it behaves more like a standard account without the customer knowing it.. which leaves more control for admin and leaves many of the normal behaviour of ZC as is.

With this comes other issues such as accessing the account pages when one should not be able to. This issues occurs during checkout when the customer enters shipping/billing addresses and then email address. Once the checkout processes receives an email address, the session now has a customer ID.. If the customer drops the cart and does something else, like hard enters the url for the account pages, they then have access to areas they shouldn't get to as guests. The observer should catch that and redirect them back to the login page. Also at this time, the dropped cart is saved in the database. When the same email address is used again during checkout the saved cart is retrieved and then added to the new cart... normal for standard accounts, not for guest. another observer to catch and delete saved carts during the checkout process for COWOA accounts only..

Testing with COWOA v2.7 on a clean install of ZC 1.5.5 using the responsive template.

Attaching the observer and loader used in ZC 1.5.4 and 1.5.5 and COWOA 2.4 - 2.7 for testing.

Hi
I'm seeing that lines 69-86 of index_dashboard.php have a misspelling for the "class=right", such as :

       echo '<div class="row"><span class="left">' . BOX_ENTRY_COUNTER_DATE . '</span><span class="rigth"> ' . $counter_startdate_formatted . '</span></div>';

The code seems to have been corrected at least once and then reverted to "class="rigth" (commit: c4a35894a14d371c65ef90c13df1adba2016db38). I've searched the latest version of both v155 and COWOA 2.6/7 on github and can find definitions in many places (e.g. stylesheet.css) and usages for class="right" but class="rigth" appears only in index_dashboard.php and has no corresponding definition anywhere.

So, maybe another attempt to correct the spelling is in order?

davewest:

I thought we added observers to COWOA! Maybe I missed something...

I've been busy converting mine which is not to bad, has some new interesting code in 1.5.5 that should make things interesting.. With the way COWOA is setup now, it behaves more like a standard account without the customer knowing it.. which leaves more control for admin and leaves many of the normal behaviour of ZC as is.

With this comes other issues such as accessing the account pages when one should not be able to. This issues occurs during checkout when the customer enters shipping/billing addresses and then email address. Once the checkout processes receives an email address, the session now has a customer ID.. If the customer drops the cart and does something else, like hard enters the url for the account pages, they then have access to areas they shouldn't get to as guests. The observer should catch that and redirect them back to the login page. Also at this time, the dropped cart is saved in the database. When the same email address is used again during checkout the saved cart is retrieved and then added to the new cart... normal for standard accounts, not for guest. another observer to catch and delete saved carts during the checkout process for COWOA accounts only..

Testing with COWOA v2.7 on a clean install of ZC 1.5.5 using the responsive template.

Attaching the observer and loader used in ZC 1.5.4 and 1.5.5 and COWOA 2.4 - 2.7 for testing.Pushed to master in Github.

DivaVocals:

Merged your PR this morning to my master repo. (https://github.com/DivaVocals/zen_COWOA) Made a few minor changes to both the v2.6 and 2.7 versions as well:

• Apply the usability updates present in COWOA v2.6 to v2.7 (changes to template and language files)

• MINOR updates to v2.6

This all needs to be tested.. I would LOVE to submit this puppy to the downloads, but before I will submit it I REALLY need the community to install it.. test it and provide REAL feedback so I know it that this has been thoroughly tested.
Diva and others. I've installed and tested this on 1.5.5 (minus the changes mentioned and and not seen any issues). I'll download the merged copy and see what's changed since I sent Jim my updates.

lucidlee:

Hi
I'm seeing that lines 69-86 of index_dashboard.php have a misspelling for the "class=right", such as :

   echo '<div class="row"><span class="left">' .  BOX_ENTRY_COUNTER_DATE . '</span><span class="rigth"> ' .  $counter_startdate_formatted . '</span></div>';

> The code seems to have been corrected at least once and then reverted to  "class="rigth" (commit: c4a35894a14d371c65ef90c13df1adba2016db38). I've  searched the latest version of both v155 and COWOA 2.6/7 on github and  can find definitions in many places (e.g. stylesheet.css) and usages for  class="right" but class="rigth" appears only in index_dashboard.php and  has no corresponding definition anywhere.
> 
> So, maybe another attempt to correct the spelling is in order?

The mispelling of this class has been present in Zen Cart going back to at least v1.3.8 or v1.3.9. I corrected it in COWOA because it simply drove me NUTS..:laugh: Looks like I missed correcting it in the new v1.5.5 **index_dashboard.php** file. I just submitted a pull request to the repo to make this correction. Please download and confirm. 

Also I want to make some additional updates to **index_dashboard.php** to pull the search form out of the table it's nested in. Forms inside of tables is invalid HTML, and I made similar corrections to the **index.php** file in the v1.5.4 compatible version of COWOA.

DivaVocals:

Also I want to make some additional updates to index_dashboard.php to pull the search form out of the table it's nested in. Forms inside of tables is invalid HTML, and I made similar corrections to the index.php file in the v1.5.4 compatible version of COWOA.

Sorry I meant to say orders.php. I want to move the search form out of the table as was done in the v1.5.4 compatible version of COWOA.

jeking:

Thank you. This one: https://github.com/DivaVocals/zen_COWOA

Tested with zencart version 1.5.5 seemed OK except I had an issue with missing Language files for checkout_success.php I needed to add the following:
define('HEADING_ORDER_NUMBER', 'Order #%s');
define('HEADING_DELIVERY_ADDRESS','Delivery Address');
define('HEADING_BILLING_ADDRESS','Billing Address');
define('HEADING_PAYMENT_METHOD','Payment Method');
define('HEADING_ORDER_DATE','Date:');
define('HEADING_ORDER_HISTORY','');
define('HEADING_QUANTITY','Qty');
define('HEADING_PRODUCTS', 'Item Name');
define('HEADING_TOTAL', 'Total');
define('TABLE_HEADING_STATUS_DATE', 'Date');
define('TABLE_HEADING_STATUS_ORDER_STATUS', 'Order Status');
define('TABLE_HEADING_STATUS_COMMENTS', 'Comments');
define('QUANTITY_SUFFIX', ' ea. ');
define('ORDER_HEADING_DIVIDER', ' - ');
Will be testing with PayPal soon.

quick question and hopefully someone will have a quick and easy answer. I have a client who simply wants only the checkout without account. This is not normal ecommerce but use of the shopping cart to sell information (sensitively) to cancer patients. For one reason or another - either they live or they die - they don't need to come back necessarily to buy another report.

So the client wants only the checkout without account so I need a redirect to only that page - not the login or the create account screen. I think I've done this before but it was a really long time ago. So quick answer to where to change the redirect and is there really only one place as I think I remember?

delia:

quick question and hopefully someone will have a quick and easy answer. I have a client who simply wants only the checkout without account. This is not normal ecommerce but use of the shopping cart to sell information (sensitively) to cancer patients. For one reason or another - either they live or they die - they don't need to come back necessarily to buy another report.

So the client wants only the checkout without account so I need a redirect to only that page - not the login or the create account screen. I think I've done this before but it was a really long time ago. So quick answer to where to change the redirect and is there really only one place as I think I remember?

I had a client with the same request. However, it was a typical ecommerce site and I strongly recommended against it. He asked to to revert back a couple of weeks later after customer complaints.

If you search this tread, you should find the solution I used.

Well, it's certainly not what I want to do, believe me. We had a big wrangle about it.

What I did was go in and change the checkout link in the shopping cart page to this:

<a href="' . zen_href_link(FILENAME_NO_ACCOUNT, '', 'SSL') . '">' . zen_image_button(BUTTON_IMAGE_CHECKOUT, BUTTON_CHECKOUT_ALT) . '</a>'; ?>

I am adding a page (because this site has been up for years) that is for folks who have bought before just in case they come back and need to buy something else. That will have links to the login and my account, etc. But removed the links to the shopping cart as well so it's a crappy user experience for someone who did.

V> ianhg:

Tested with zencart version 1.5.5 seemed OK except I had an issue with missing Language files for checkout_success.php I needed to add the following:
define('HEADING_ORDER_NUMBER', 'Order #%s');
define('HEADING_DELIVERY_ADDRESS','Delivery Address');
define('HEADING_BILLING_ADDRESS','Billing Address');
define('HEADING_PAYMENT_METHOD','Payment Method');
define('HEADING_ORDER_DATE','Date:');
define('HEADING_ORDER_HISTORY','');
define('HEADING_QUANTITY','Qty');
define('HEADING_PRODUCTS', 'Item Name');
define('HEADING_TOTAL', 'Total');
define('TABLE_HEADING_STATUS_DATE', 'Date');
define('TABLE_HEADING_STATUS_ORDER_STATUS', 'Order Status');
define('TABLE_HEADING_STATUS_COMMENTS', 'Comments');
define('QUANTITY_SUFFIX', ' ea. ');
define('ORDER_HEADING_DIVIDER', ' - ');
Will be testing with PayPal soon.

Good catch.. Made these updates..

Hi everybody

There seems to be a security issue with Cowoa. I just tested with ZC 1.5.5 and Cowoa 2.7 (latest in Github):

1. Person A makes an order from Zen Cart using Cowoa checkout using email [email protected]
2. Person B user makes a new account to Zen Cart using the same email address [email protected]
3. Person B now sees order that Person A made in step 1. which is the security issue I am talking about

This is due to registering doesn't use email confirmation by default... It isn't normally a issue if someone registers with a faulty email they have no access to, not really a major issue. However when using Cowoa, this reveals sensitive data about users and their order history.

I am currently trying to figure how to fix this problem in my customers site, and basically I'm rather unsure how to fix it. I suppose email-confirmation must be required when cowoa-account exists before upgrading it to a normal account. Or mark orders to cowoa-orders, and not display them to a non-cowoa users.

Jarkko:

Hi everybody

There seems to be a security issue with Cowoa. I just tested with ZC 1.5.5 and Cowoa 2.7 (latest in Github):

1. Person A makes an order from Zen Cart using Cowoa checkout using email [email protected]
2. Person B user makes a new account to Zen Cart using the same email address [email protected]
3. Person B now sees order that Person A made in step 1. which is the security issue I am talking about

This is due to registering doesn't use email confirmation by default... It isn't normally a issue if someone registers with a faulty email they have no access to, not really a major issue. However when using Cowoa, this reveals sensitive data about users and their order history.

I am currently trying to figure how to fix this problem in my customers site, and basically I'm rather unsure how to fix it. I suppose email-confirmation must be required when cowoa-account exists before upgrading it to a normal account. Or mark orders to cowoa-orders, and not display them to a non-cowoa users.

I made a quick fix to this problem in my installation by modifying includes/modules/pages/account/header_php.php and includes/modules/pages/account_history/header_php.php with following line added to sql-query in both files:

AND    o.COWOA_order = 0

So account and account_history will only show orders that are not Cowoa-orders.

Also while testing I noticed that order_status -page can easily be brute-forced to give out information about orders for desired email. So I also took that feature off from the admin area, and deleted the includes/modules/pages/order_status -folder (since it kept working even after feature was disabled).

Jarkko:

I made a quick fix to this problem in my installation by modifying includes/modules/pages/account/header_php.php and includes/modules/pages/account_history/header_php.php with following line added to sql-query in both files:

AND o.COWOA_order = 0

> 
> So account and account_history will only show orders that are not Cowoa-orders.
While I don't have a fix to share, I do want to point out that this suggested fix is a bandaid solution IMHO, and probably not a desireable long term solution. If one starts out as a guest customer and decides to convert to a standard account using the same email address, I would think that the desired behavior is to see their entire order history (guest sales as well as standard account sales).

On an unrelated side note.. 2 more posts to my 10,000th post on this forum!! :clap:

It depends on your idea of security risk or user convenience.

My two pennies..

Yes, COWOA always had that issue so does other sites that use email address as the user ID. I don't think I've actually had a shopping site do a opt-in opt-out check on account creation or checkout like non-shopping sites do.. wouldn't be hard to code in, but its another announce to the shopper!

What I mean by opt-in opt-out, during the account sign up or creation you enter an email address, an email is sent with a standard is this you message, if so type in this number or click this link to finish or activate your account! I don't think you would get a customer to finish checking out if that happens... This is the only way I know of to prevent email address ID abuse for any site.... not just COWOA!

COWOA assumes that the email address is one of a kind which it is unless you gave it up and someone decide to reuse it for themselves, then comes to your shop and creates an account.. If your storing more then shipping addresses, order details.. like CC numbers!! then yes I can see this as more then a COWOA security issue. I've also thought about what if someone decides to use someone email address and creates an standard account or cowoa checkout... buys and ships to there address! As a business owner I'm assuming you are managing the billing/payment side with fraud protection.. I am!

Accessing a COWOA account by using the login side of ZC should be very hard.. COWOA accounts are protected with a password, for me, its a large hash, random character set, then salted... making a very hard password. I think ZC155 does this now which means I'll be switching that could out and using ZC call.

I agree that the order status code can use better sanitizing and protection... will work on that.

If you don't want your customers to see past orders, wouldn't be hard to code in a switch for that, but if you don't want them to find out the order status, then you can turn off or un-code that for your site if you wish to leave customers in the dark.. I don't hide the order status page and it's available to both cowoa and standard customers... I don't see a need or reason for someone to turn that feature off, but you can by not adding the page and link to your site.

davewest:

It depends on your idea of security risk or user convenience.

My two pennies..

Yes, COWOA always had that issue so does other sites that use email address as the user ID. I don't think I've actually had a shopping site do a opt-in opt-out check on account creation or checkout like non-shopping sites do.. wouldn't be hard to code in, but its another announce to the shopper!

What I mean by opt-in opt-out, during the account sign up or creation you enter an email address, an email is sent with a standard is this you message, if so type in this number or click this link to finish or activate your account! I don't think you would get a customer to finish checking out if that happens... This is the only way I know of to prevent email address ID abuse for any site.... not just COWOA!

COWOA assumes that the email address is one of a kind which it is unless you gave it up and someone decide to reuse it for themselves, then comes to your shop and creates an account.. If your storing more then shipping addresses, order details.. like CC numbers!! then yes I can see this as more then a COWOA security issue. I've also thought about what if someone decides to use someone email address and creates an standard account or cowoa checkout... buys and ships to there address! As a business owner I'm assuming you are managing the billing/payment side with fraud protection.. I am!

Accessing a COWOA account by using the login side of ZC should be very hard.. COWOA accounts are protected with a password, for me, its a large hash, random character set, then salted... making a very hard password. I think ZC155 does this now which means I'll be switching that could out and using ZC call.

I agree that the order status code can use better sanitizing and protection... will work on that.

If you don't want your customers to see past orders, wouldn't be hard to code in a switch for that, but if you don't want them to find out the order status, then you can turn off or un-code that for your site if you wish to leave customers in the dark.. I don't hide the order status page and it's available to both cowoa and standard customers... I don't see a need or reason for someone to turn that feature off, but you can by not adding the page and link to your site.

nods in agreement:yes:

I should have been clear that I don't think this is a SECURITY issue.. It MIGHT be a NUISANCE issue if you actually have folks doing this..

I have no knowledge of anyone reporting this "issue" with regards to COWOA or Fast & Easy Checkout in any support post on this forum.

I don't think that there is any GAIN by any hacker or prankster trying to access a CUSTOMER side account. I suspect that the Zen Cart admins and community would have reported such and it would have been addressed.