Admin Profiles (for v1.3.x only!) Support Thread

[mmand]

I'm not sure if you are aware, but there is a small bug in the latest versions' SQL patch.

Lines 268-276 read:

#
# Create table structure for table `admin_allowed_categories`
#

DROP TABLE IF EXISTS `admin_allowed_categories`;
CREATE TABLE `admin_allowed_pages` (
  `categories_id` int(11) NOT NULL default '0',
  `admin_id` int(11) NOT NULL default '0'
) TYPE=MyISAM;

Line 273 should read:

CREATE TABLE `admin_allowed_categories` (

I've just installed this, and will be giving it a spin shortly.

[kuroi]

I'm not sure if you are aware, but there is a small bug in the latest versions' SQL patch.

I think you must be referring to the Admin Users - Restrict Product Categories mod.

This is the support thread for Admin Profiles which does not have the admin_allowed_categories table.

[AndyII]

i pointed that out a while ago about the SQL patch......
isn't it ironic that after I had this developed for more restrictions, that someone would use an exact table name as I created?
seems suspicious , makes me wonder if someone is sharing stuff they shouldn't be sharing

[mmand]

I think you must be referring to the Admin Users - Restrict Product Categories mod.

This is the support thread for Admin Profiles which does not have the admin_allowed_categories table.

Sorry, this was the support topic listed in the readme. I didn't realize the author of Admin Users hadn't changed any of that.

[kuroi]

Sorry, this was the support topic listed in the readme. I didn't realize the author of Admin Users hadn't changed any of that.

No problem. It was the author's intention that it would be an extension of this mod, but there were concerns over the extent to which it actually delivered what it set out to do, so it was moved of into a separate mod to keep it distinct from this one which is much more robust. Credit to you for taking the time to alert people to a problem and give a solution.

[kuroi]

i pointed that out a while ago about the SQL patch......
isn't it ironic that after I had this developed for more restrictions, that someone would use an exact table name as I created?
seems suspicious , makes me wonder if someone is sharing stuff they shouldn't be sharing

The author of Admin Users and I have chatted about his mod and I'm pretty convinced that he is using code that he amended himself.

That said, I can't see any way that restrictions by category could be done properly without significant amendments to existing Zen Cart code, so if you are trying to restrict people from re-distributing your code, it either doesn't do the job properly or you are in violation of the GPL license.

[yellow1912]

Kuroi, what if we do something like this:

<?php
/**
 * @package admin
 * @copyright Copyright 2003-2007 Zen Cart Development Team
 * @copyright Portions Copyright 2003 osCommerce
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: catalog_dhtml.php 6050 2007-03-24 03:20:50Z ajeh $
 */
if (!defined('IS_ADMIN_FLAG')) {
  die('Illegal Access');
}
  $za_contents = array();
  $za_heading = array('text' => BOX_HEADING_CATALOG, 'link' => zen_href_link(FILENAME_ALT_NAV, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_CATEGORIES_PRODUCTS, 'link' => zen_href_link(FILENAME_CATEGORIES, '', 'NONSSL'));

  $za_contents[] = array('text' => BOX_CATALOG_PRODUCT_TYPES, 'link' => zen_href_link(FILENAME_PRODUCT_TYPES, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_PRODUCTS_PRICE_MANAGER, 'link' => zen_href_link(FILENAME_PRODUCTS_PRICE_MANAGER, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_CATEGORIES_OPTIONS_NAME_MANAGER, 'link' => zen_href_link(FILENAME_OPTIONS_NAME_MANAGER, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_CATEGORIES_OPTIONS_VALUES_MANAGER, 'link' => zen_href_link(FILENAME_OPTIONS_VALUES_MANAGER, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_CATEGORIES_ATTRIBUTES_CONTROLLER, 'link' => zen_href_link(FILENAME_ATTRIBUTES_CONTROLLER, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_CATEGORIES_ATTRIBUTES_DOWNLOADS_MANAGER, 'link' => zen_href_link(FILENAME_DOWNLOADS_MANAGER, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_PRODUCT_OPTIONS_NAME, 'link' => zen_href_link(FILENAME_PRODUCTS_OPTIONS_NAME, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_PRODUCT_OPTIONS_VALUES, 'link' => zen_href_link(FILENAME_PRODUCTS_OPTIONS_VALUES, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_MANUFACTURERS, 'link' => zen_href_link(FILENAME_MANUFACTURERS, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_REVIEWS, 'link' => zen_href_link(FILENAME_REVIEWS, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_SPECIALS, 'link' => zen_href_link(FILENAME_SPECIALS, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_FEATURED, 'link' => zen_href_link(FILENAME_FEATURED, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_SALEMAKER, 'link' => zen_href_link(FILENAME_SALEMAKER, '', 'NONSSL'));
  $za_contents[] = array('text' => BOX_CATALOG_PRODUCTS_EXPECTED, 'link' => zen_href_link(FILENAME_PRODUCTS_EXPECTED, '', 'NONSSL'));


if ($za_dir = @dir(DIR_WS_BOXES . 'extra_boxes')) {
  while ($zv_file = $za_dir->read()) {
    if (preg_match('/catalog_dhtml.php$/', $zv_file)) {
      require(DIR_WS_BOXES . 'extra_boxes/' . $zv_file);
    }
  }
  $za_dir->close();
}

foreach ($za_contents as $key => $value) {
    if (page_allowed($value['link'])!='true') unset($za_contents[$key] );
  }
?>
<!-- catalog //-->
<?php
echo zen_draw_admin_box($za_heading, $za_contents);
?>
<!-- catalog_eof //-->

Of course we will have to change the algorithm of function page_allowed a bit, since we pass in the link, not the page.
We will have to get the page from that link, which is easy.

The beauty of this, is that you dont have to edit any 3rd module box at all. And keep the modification of core code to the minimum.

[kuroi]

Of course we will have to change the algorithm of function page_allowed a bit, since we pass in the link, not the page.
We will have to get the page from that link, which is easy.

The beauty of this, is that you dont have to edit any 3rd module box at all. And keep the modification of core code to the minimum.

If I understand correctly what you're suggesting the page_allowed algorithm would need to be expanded enormously.

The approach that you're suggesting appears to be predicated on the idea that the $_GET variable contains the information needed to be able to determine whether an Admin User should be permitted to access a particular function.

There are two problems with this:
1. from an access control perspective we should be stopping users from attempting actions for which they don't have permission rather than rejecting those actions once taken; and
2. the information needed will often be part of an array in the $_POST variable, or worse, implicit in apparently unrelated information.

For example: if we were restricting users so that they could affect only products which they had originated (the most commoin reason for this request) we may want them to be able to create coupons for their products. Once there are coupons available they need to be maintained. This could mean increasing or decreasing the rate.

Obviously we don't want users playing with the discounts available for products that aren't theirs. But the coupon URLs don't give us the information necessary to make this determination so we would need new code in the allowed_pages algorithm to look-up the coupon and find out which products it applies to and then more code to find out whether these products are in permitted categories.

There are literally dozens of analagous examples spread through the Admin. So that algorithm would become very large and complex very quickly.

But even if we caught them all and the code worked, it would still be unsatisfactory since it users would not be prevented from browsing information containing products outside their category, and would experience frustrating rejections of actions that appeared to be legitimate and allowed.

[yellow1912]

No, not really.

Lets get back to what you have:

$options = array( array( 'page' => FILENAME_REVIEWS, 'box' => BOX_CATALOG_REVIEWS), 

Basically, you the pass the 'page' into this function page_allowed

Now, what if you accept the original array?

$za_contents[] = array('text' => BOX_CATALOG_REVIEWS, 'link' => zen_href_link(FILENAME_REVIEWS, '', 'NONSSL')); 

So, what I am saying is, in the case you will have to pass a already built link, so what you have to do is from that already built link, you have to get back FILENAME_REVIEWS, which is not hard.
So basically you dont change the algorithm of that function, but you add the piece of code that would get the 'page' back from the generated 'link'

[mmand]

No problem. It was the author's intention that it would be an extension of this mod, but there were concerns over the extent to which it actually delivered what it set out to do, so it was moved of into a separate mod to keep it distinct from this one which is much more robust. Credit to you for taking the time to alert people to a problem and give a solution.

Forgive me for not looking through 57 pages in this topic...I don't really have the time right now.

I was hoping you found a way to display a different index.php for restricted users. (RE: page 16ish.) I've tried playing with the code myself, but I know so little about ZenCart that nothing I did would change anything.

Thanks in advance.