Category Specific Access Restriction (CSAR) - [Support Thread]

[lucidlee]

I'm using the v1.5.4 friendly version of Integrated COWOA 2.6 that DivaVocals is working on: https://github.com/DivaVocals/zen_COWOA, although there are hassled integrating that with SuperOrders/Edit Orders/ etc if one uses them

[frank18]

I'm using the v1.5.4 friendly version of Integrated COWOA 2.6 that DivaVocals is working on: https://github.com/DivaVocals/zen_COWOA, although there are hassled integrating that with SuperOrders/Edit Orders/ etc if one uses them

OK, I got my copy from the Plugins - I will have a look at COWOA 2.6 a bit later.

Edit: that is a beta version! Suggest not to use it until the final version is released.

[lucidlee]

Yes its a beta but it works better in v1.5.4 than does the older v2.4. It does seem to be adhering to the most recent ZenCart coding practices which is one reason why I'm having so much difficulty merging CSAR in.

[frank18]

Yes its a beta but it works better in v1.5.4 than does the older v2.4. It does seem to be adhering to the most recent ZenCart coding practices which is one reason why I'm having so much difficulty merging CSAR in.

Judging by your initial post re merging the 2 mods, the COWOA admin/customers.php file has not been upgraded as yet. I have not checked and guess DivaVocals would be the person to contact to clarify.

Until DivaVocals has completed all of COWOA 2.6 and released an official version I would not attempt merging the 2 mods.

[chibipaw]

Sorry for resurrecting this very old post. I've been testing this version 2.12 of this mod on my 1.5.4 server.
Was this bug patched in the release package of v2.12?
Looks like I am able to circumvent this restriction by using Ajeh's method of using any non-restricted category + restricted product id in a url.
Here's what I've discovered:
If Im not logged in as a user, and try to directly access a restricted product. It'll throw a simple one line note of "OOPS - ILLEGAL ACCESS !".
However, if I am logged in as a valid user, but this user is NOT a privileged user, I was able to view and add the product to the user's shopping basket.

I've attempted to apply the hot fix codes in post #9 by replacing the first part of tpl_document_product_info_display.php. Didn't seem to change any of the behavior. But I figured it shouldn't be, since the post is very old, and looks like its for a versions before 2.0.

Lastly, products by Manufacturer doesn't seem to work at all. Which file controls this anyways? Im guessing it is the default_filter.php file.

Any help would appreciate it. I have a some what cult like following for my products, and my customers are extremely crafty in which I have people engineered bots for walking my catalog for scalping, but many users have actually been guessing incremental product numbers for finding newly created but hidden products. Which I really want to put an end to.

Any help is greatly appreciated.

Plugged the security hole.

File /includes/templates/MY_TEMPLATE/templates/tpl_product_info_display.php amended to this:

[ file header here]

<?php 
/** 
* CATEGORY_RESTRICTION - find corresponding master category for the current product 
 */ 
$products_id_to_block = $_GET['products_id']; 
global $db; 
$sql = "select master_categories_id from " . TABLE_PRODUCTS . " where products_id = :productID:"; 
$sql = $db->bindVars($sql, ':productID:', $products_id_to_block, 'integer'); 
$result = $db->Execute($sql); 
 
if ($result->RecordCount() > 0) { 
  echo '(used for testing purposes): Master Category ID = ' . $result->fields['master_categories_id']; 
} else { 
  echo 'Sorry, no record found for product number ' . $products_id_to_block; 
} 
 
if (!$_SESSION['customer_id'] && !$_SESSION['customers_privileges'] > 0 && in_array($result->fields['master_categories_id'],explode(',', CATEGORY_RESTRICTION_LOGIN_CATEGORY)) ) { 
 //echo ' - this product should be blocked !!'; 
 echo TEXT_ILLEGAL_ACCESS ; 
} else { // bof CATEGORY_RESTRICTION - OPEN ACCESS 

.... orginal body of the file

.... then at the bottom added after 
<!--bof Form close-->
 
<?php 
    } // eof CATEGORY_RESTRICTION - OPEN ACCESS 
?> 
</div>

Thanks again for pointing this out Ajeh!

[frank18]

.....
Here's what I've discovered:
If Im not logged in as a user, and try to directly access a restricted product. It'll throw a simple one line note of "OOPS - ILLEGAL ACCESS !".
However, if I am logged in as a valid user, but this user is NOT a privileged user, I was able to view and add the product to the user's shopping basket.

I've attempted to apply the hot fix codes in post #9 by replacing the first part of tpl_document_product_info_display.php. Didn't seem to change any of the behavior. But I figured it shouldn't be, since the post is very old, and looks like its for a versions before 2.0.

Lastly, products by Manufacturer doesn't seem to work at all. Which file controls this anyways? Im guessing it is the default_filter.php file. .....

Thank you for the heads up. I will have a look at this in the next couple of days. Just returned from a trip to Melbourne and have a pile of (paying) jobs to attend first.

Leave it with me

Cheers / Frank

[chibipaw]

Thanks Frank.

Another thing to consider. My tester had found another bypass using submitting form using Firebug. I have too notice that the view basket/cart function doesn't seem to sanity check for products that are prohibited. Here's the synopsis of his findings. Hope this helps.

Requirements:
Firefox with FireBug Plugin ( https://addons.mozilla.org/en-US/firefox/addon/firebug/ )

If the user loads a non-restricted item page, and then opens the page in firebug, they can edit the following tag in the "Add to Cart Box" section:
<input type="hidden" name="products_id" value="11321" />
to input any ID, restricted or otherwise. Then the user can click the Add to Cart button, and the item will be added successfully without any restriction checking done.

Thank you for the heads up. I will have a look at this in the next couple of days. Just returned from a trip to Melbourne and have a pile of (paying) jobs to attend first.

Leave it with me

Cheers / Frank

[frank18]

......
Looks like I am able to circumvent this restriction by using Ajeh's method of using any non-restricted category + restricted product id in a url.
Here's what I've discovered:
If Im not logged in as a user, and try to directly access a restricted product. It'll throw a simple one line note of "OOPS - ILLEGAL ACCESS !".
However, if I am logged in as a valid user, but this user is NOT a privileged user, I was able to view and add the product to the user's shopping basket.

I've attempted to apply the hot fix codes in post #9 by replacing the first part of tpl_document_product_info_display.php. Didn't seem to change any of the behavior. But I figured it shouldn't be, since the post is very old, and looks like its for a versions before 2.0.

Yep, I could reproduce that.

Open the file /includes/templates/MY_TEMPLATE/templates/tpl_product_info_display.php, find

if (!$_SESSION['customer_id'] && !$_SESSION['customers_privileges'] > 0 && in_array($result->fields['master_categories_id'],explode(',', CATEGORY_RESTRICTION_LOGIN_CATEGORY)) ) { 
 // block access to this product 
  echo TEXT_ILLEGAL_ACCESS ;

removed the part in red, change to

if (!$_SESSION['customers_privileges'] > 0 && in_array($result->fields['master_categories_id'],explode(',', CATEGORY_RESTRICTION_LOGIN_CATEGORY)) ) { 
 // block access to this product 
  echo TEXT_ILLEGAL_ACCESS ;

It is marked for the next updated version.

......
Lastly, products by Manufacturer doesn't seem to work at all. Which file controls this anyways? Im guessing it is the default_filter.php file.

Sorry, I can't reproduce this, you may want to check for merging errors. Products by manufacturer works fine in a few test sites and also on a live 1.5.5a store.

[chibipaw]

Thanks for the update. Excited to finally patch this hole before anyone figures it out.

On manufacturer checking issue, which are the best files to look into first to diagnose this?

Thanks.

[frank18]

Thanks for the update. Excited to finally patch this hole before anyone figures it out.

On manufacturer checking issue, which are the best files to look into first to diagnose this?

Thanks.

Just in the process of parceling up CSAR 2.2.0 modified for ZC 1.5.5a and will submit in the next day or so.

PM me your email and I send you a copy of the pack in the next day or 2.