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

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.

mmand:

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.

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:oops:

kuroi:

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. :blush:

mmand:

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. :blush: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.

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:oops: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.

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.

yellow1912:

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.

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?

```php
$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'

kuroi:

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.

Okie, kuroi, so I went ahead and made the changes, and it seems to work pretty well, here is what I do:

First, Go to the admin/includes/boxes, assuming all the files there are the original ones:
I overwrite configuration_dhtml.php using your file.
For the rest, I search for:

$za_dir->close();
}

And add below:

foreach ($za_contents as $key => $value) {
    if (page_allowed($value['link'])!='true') unset($za_contents[$key]);
}

Now I edit admin/includes/functions/admin_profiles.php

I search for:```php
$page = strip_suffix($page,".php");

Add right above it:
```php
if(strpos($page, HTTP_SERVER) !== false || strpos($page, HTTPS_SERVER) !== false){
        $page = current(explode('?', end(explode('/', $page))));
    }

Done!

Kuroi, I attach here I modified version, let me know what you think. All seem to work well, except 1 minor possible bug caused by me:

Under Extras, the first link seems to be blank, but when you click on it you will go to the admin profiles.

@yellow1912

I get it now. We were talking at cross-purposes.

The post to which you replied originally was about an attempt to restrict users to a particular categories or set of categories. The problem that you are attempting to resolve, is how to avoid the need for restructuring the box files - different but still a very worthy objective.

I've looked at your code, installed it up and given it a run out and I like it. There are two very good ideas in there that minimise the changes needed to the box files. However, following your lead, I think that we can do away with the final change too - a significant step forward in the ease of installation and use of this mod. I've some more changes and testing to do, but this is looking good.

:thumbsup:

I have an issue for which I'm hoping someone can offer suggestions: I'm working with a new 1.3.8 install - no mods or add-ons except Admin profiles. I first did an install of both on a local test server - no hitches at all - worked like a charm. I then installed them onto a shared host server. Except this time, on the public server install, when I log in and try to set permissions for a user profile and click "save changes", there's a pause and then i'm returned to the admin login page (essentially i get booted out). I can log back in and can verfiy that any permissions changes requested are lost instead of applied.

I've scoped around and all other admin functionality seems to be intact and unaffected - meaning i can add a new admin user, delete it, add / edit products, make other config changes etc, etc ....but only changes to an admin's permissions seem to cause the rejection. I verified that the tables were added to the database - and they seem to be in order and populated with the same data specified in the install script. I even removed and re-uploaded new admin profiles php files - to no avail.

I did notice that, on the problematic installation, that the Admin with admin_id = 1 was set with an admin_level = 0. This, when compared to my local install, was found to be different - my local admin_id 1 also had a admin_level = 1. I tried manually assigning this value from 0 to 1 but it seems to have had no effect. I still am booted as soon as I try to save permissions changes on this public server.

Any suggestions??

kuroi:

If when installing other mods you over-write the Admin Profiles files then it will stop working, partially or completely. Though I puzzled as to how you would do that when installing Image Handler as that mostly adds rather than replaces existing files. But I would look carefully at your box files, as these are the ones that would have the efect that you describe.

box files??

what would i been looking for?? this problem is on a fresh install of 1.3.8a and the only thing i have done is installed my template and installed IH and AP

IH and AP have no common files that are over writen. Its a wierd error!!!

Great! Cant wait to see the new version ^_^> kuroi:

@yellow1912

I get it now. We were talking at cross-purposes.

The post to which you replied originally was about an attempt to restrict users to a particular categories or set of categories. The problem that you are attempting to resolve, is how to avoid the need for restructuring the box files - different but still a very worthy objective.

I've looked at your code, installed it up and given it a run out and I like it. There are two very good ideas in there that minimise the changes needed to the box files. However, following your lead, I think that we can do away with the final change too - a significant step forward in the ease of installation and use of this mod. I've some more changes and testing to do, but this is looking good.

:thumbsup:

No response to my earlier post for assistance so i've been attempting to resolve the issue myself - but to no avail. Sigh...:frusty:

What i've done: I've removed Zen cart entirely from my public host (including the database) and reinstalled fresh. This is a fresh 1.3.8a with the first and only mod installed is Admin Profiles 1.0.7. Not even a custom template, products, categories or anything - just ZC and AP straight from the "boxes" so to speak. The install of AP was followed to the letter - including the patch files.

ZC and it's Admin seems to work just fine - including the creation and editing of new admin users. However, every time i attempt to edit an admin's user permissions, i am just booted back to the admin login screen. Very frustrating.

The most frustrating thing about all this is that my localhost install works just fine - i just can't get AP to run on my shared hosts' server. Too bad because my primary interest in ZC was for the availability of AP.

Any assitance/suggestions would be greaty appreciated.

stride-r:

every time i attempt to edit an admin's user permissions, i am just booted back to the admin login screen. Very frustrating.Is this when you try to enter the settings screen or when you try to save the results?

If it's the former, are you clicking in the yellow symbol or on the button? If you hover over either what URL appears in the box left hand corner of your browser?

kuroi:

Is this when you try to enter the settings screen or when you try to save the results?

If it's the former, are you clicking in the yellow symbol or on the button? If you hover over either what URL appears in the box left hand corner of your browser?

No, it's not just a user error. :wink: This happens when i try to save any changes made to the permissions.

FYI - My admin account (id=1) shows full permissions already (everything is checked), a newly created test user however is a blank slate (which i believe is normal). When i try to save any newly assigned permissions for this test user, i get booted out. Same thing happens when i try to edit my own permissions.

I have a basic question on the admin profile install and I'm so green at this you will have to talk to me like I'm a toddler. Explain it. I have read and reread the instructions.

Here is where I am. I'm have backed up my databases. I see where it says to run the sql install. I go to zencart and tools>install sql patches

I am lost here. I see where I can upload the sql patch but do I put anything in the box where it says enter the query to be executed? Or do I just browse for the file and upload install_admin_profile.sql

next: I understand how to drop the admin file in the admin file on the ftp but do I do anything with the extra one? I don't know if anything has been done because I paid someone to install it for me. The version is 1.3.8a That being said i guess if I don't have it working right I need to drop the extras folder into admin ftp also....Right?:shocking:

At this point it should be working if I did the above correctly, am I right?

I asked about having the same person do this install for me but she wanted to charge me so I want to attempt this myself so I can save the money.

Hopefully y'all can instruct me better. Please....:unsure: