Admin View Permissions & Child Pages Site Map

This is the place to report bugs and get support. When posting in this forum, please always provide as much detail as possible.

Please do not report problems with a custom build or custom code in this forum. If you are producing your own build from the source code and have problems or questions, ask in the developer forum, do not report it as a bug.

This is the place to report bugs and get support

When posting in this forum, please try to provide as many relevant details as possible. Particularly the following:

  • What operating system were you running when the bug appeared?
  • What database platform is your site using?
  • What version of mojoPortal are you running?
  • What version of .NET do you use?
  • What steps are necessary to reproduce the issue? Compare expected results vs actual results.
Please do not report problems with a custom build or custom code in this forum. If you are producing your own build from the source code and have problems or questions, ask in the developer forum.
This thread is closed to new posts. You must sign in to post in the forums.
9/14/2011 2:54:05 PM
Gravatar
Total Posts 156

Admin View Permissions & Child Pages Site Map

Windows Server 2008
MSSQL 2008 R2
mojoPortal 2.3.6.6

Admin View Permissions and Child Pages Site Map

 


According to http://www.mojoportal.com/rolesandpermissions.aspx, "if you explicitly set a view/edit permission to admins only then members of Content Administrators cannot edit/view it."

However, this does not hold true in practice.  I set up a test user with a Authenticated User and Content Administrators roles ONLY, set the view permissions on a page to Administrators only, but the Content Administrator was still able to access the page.

Also, when I check "Show Child Pages Site Map" in Page Settings, no site map is being displayed on the page even though all of the child pages have "Include In Child Pages Site Map" enabled.

9/16/2011 6:32:25 AM
Gravatar
Total Posts 18439

Re: Admin View Permissions & Child Pages Site Map

Can you reproduce the problem on the demo site? I think this has been reported recently and fixed.

Best,

Joe

9/16/2011 12:35:01 PM
Gravatar
Total Posts 156

Re: Admin View Permissions & Child Pages Site Map

The child site map appears to have been fixed on the demo site which runs 2.6.3.9.  However, I was still able to reproduce the permission issue on your demo site: http://demo.mojoportal.com/admins-only

if you log in as admin@admin.com, you can see the page, but I also created a testuser@test.com  (password: mojotest009), which belongs to the content administrators and authenticated user roles ONLY.  Even though the view permissions on that page are set to Administrators only, testuser@test.com is still able to view the page.

9/17/2011 1:59:49 PM
Gravatar
Total Posts 18439

Re: Admin View Permissions & Child Pages Site Map

This is now fixed in the source code repository. Can you test it out and confirm it?

Thanks,

Joe

11/3/2011 3:56:25 PM
Gravatar
Total Posts 156

Re: Admin View Permissions & Child Pages Site Map

2.3.70 has fixed the issue reported originally.  However, we ran into nasty issues with our "Content Administrators" here and I had to take a closer look.

Here is what I noticed on the Demo Site:

When "Administrators" is the only role selected under "Roles that can edit this page"
- "Content Administrators" can still:

  1. Go to "Page Settings"
  2. Go to "Edit This Page"
  3. Go to any content's "Settings" residing on this page which allows them to go into "Security" tab of that content and add themselves to "Roles that can edit content"

Q1: Why would a Content Administrator be allowed to go into the Page Settings, Edit This Page,  and Settings of any content (module) residing on the page if "Administrators" had exclusive rights under "Roles that can edit this page?"

Q2: Should module security settings override the security settings of the page on which it resides?

 

Now here are the issues that we are currently facing with "Content Administrators" after having updated to 2.3.7.0:

  1. Can't uncheck "Administrators" checkbox under "Rules that can view this page," "Roles that can edit this page," and "Roles that can create pages below this page."  Somehow I'm able to uncheck "Administrators"  under "Roles that can only edit this page as draft."  Strangely enough, the "Administrators"  checkbox gets checked automatically under those three areas even when I create a brand new page at the root (to avoid inheriting from a parent page).  What's even more peculiar is that despite checkboxes being checked in those three areas the page permissions do appear to be changed, so this is a UI issue as after "Save" is hit, the "Administrators" boxes should be unchecked and they simply aren't. I was not able to reproduce this behavior on the demo site.
  2. "Content Administrators" can't access content (module) settings of any content on the site no matter what the page permissions are.  In other words, even if "Content Administrators" can edit the content (module), they can't access the settings still. I was not able to reproduce this behavior on the demo site.
11/3/2011 4:16:18 PM
Gravatar
Total Posts 1203
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Admin View Permissions & Child Pages Site Map

Your issue #1 sounds like a potential inconsistent display bug, but Joe may have some other ideas on that one.

#2 could be a bug, but there's a key that might be affecting it too. Check to see if you have "HideModuleSettingsGeneralAndSecurityTabsFromNonAdmins" enabled, and if so, turn it off and see if that makes a difference. I'm not sure if that affects Content Administrators, but it's worth a try. I seem to remember that there's at least one other setting that's able to hide the "settings" option, but I can't remember offhand what it is, and I can't find it right now. I'm sure Joe will know.

I hope that helps,
Jamie

11/3/2011 4:40:52 PM
Gravatar
Total Posts 156

Re: Admin View Permissions & Child Pages Site Map

Jamie, that setting is strictly for General & Security tabs to be hidden from non admins, it does not prevent "Content Administrators" from going into settings.  It was set to true, I tried setting it to false just to double-check and it did not make any difference.

11/4/2011 8:15:56 AM
Gravatar
Total Posts 18439

Re: Admin View Permissions & Child Pages Site Map

"Content Administrators" can't access content (module) settings of any content on the site no matter what the page permissions are.  In other words, even if "Content Administrators" can edit the content (module), they can't access the settings still. I was not able to reproduce this behavior on the demo site.

I think that was patched in latest patch to version 2.3.7.0, you may need to download it again and replace mojoPortal.Web.dll.

I'm investigating the page edit questions now and will post again.

Q2: Should module security settings override the security settings of the page on which it resides?

They are supplemental to page security settings. To secure a content instance so that only admins can edit it you should set that on both the page and the module, otherwise the content administrator may be able to get to it from Content Manager where there is no page context and therefore no page permissions applied.

Best,

Joe

11/4/2011 9:44:32 AM
Gravatar
Total Posts 18439

Re: Admin View Permissions & Child Pages Site Map

Hi,

I've looked into the Admin only scenario and found several things that were not handled correctly, I believe these things have been incorrect for quite a while but not many people know about the admin only functionality and therefore not many use it so it hasn't been reported a lot.

I've created a patch that can be downloaded here. There is only one file in the patch, mojoPortal.Web.dll but 2 versions of it, one for .NET 3.5 and one for .NET 4.

While I have made several patches to the 2.3.7.0 packages already, I'm not able to update that release anymore because I've already submitted it to the Web App Gallery and that entails creating an sha1 hash of the file so if I update the file now it will break installations from the web app gallery once the file goes live. That is why I usually wait a while before submitting new release to the gallery, because it allows time in case there are any bugs reported that can be patched easily, but I submitted version 2.3.7.0 yesterday. So any new fixes require releasing a new version. More than likely there will be a new release this month anyway so for now anyone affected by this issue should just download and apply the patch linked above.

These fixes are also now in the source code repository.

Thanks,

Joe

11/4/2011 5:14:13 PM
Gravatar
Total Posts 156

Re: Admin View Permissions & Child Pages Site Map

I did some more investigating to see what was causing the "Administrators" checkbox to show up selected even though it was unselected before the "Save" button was hit.  Turns out, the UI bug is prevalent when UserRelatedSiteMode is enabled and the user belongs to a role in  siteSettings.SiteRootEditRoles. Since "Administrators" role was set to be a site editor for our child site (which might make little sense, but that's beside the point), when an Administrator modifies the page permissions, the following checkboxes will always appear selected even though mp_Pages table gets updated when they are first unchecked and "Save" is pressed:

  1. "Administrators" under "Roles that can view this page"
  2. "Administrators" under "Roles that can edit this page"
  3. "Content Authors" under "Roles that can only edit this page as draft"
  4. "Administrators" under "Roles that can create pages below this page"

This code snippet from PageSettings.aspx.cs is the reason they always show up selected:
 

using (IDataReader reader = Role.GetSiteRoles(siteSettings.SiteId))
{
                while (reader.Read())
                {

 

                    ListItem listItem = new ListItem();
                    listItem.Text = reader["DisplayName"].ToString();
                    listItem.Value = reader["RoleName"].ToString();

 

                    ListItem editItem = new ListItem();
                    editItem.Text = reader["DisplayName"].ToString();
                    editItem.Value = reader["RoleName"].ToString();

 

                    ListItem draftItem = new ListItem();
                    draftItem.Text = reader["DisplayName"].ToString();
                    draftItem.Value = reader["RoleName"].ToString();

 

                    ListItem childItem = new ListItem();
                    childItem.Text = reader["DisplayName"].ToString();
                    childItem.Value = reader["RoleName"].ToString();

 


                    if (
                        (pageSettings.AuthorizedRoles.LastIndexOf(listItem.Value + ";") > -1)
                        || ((isSiteEditor) && (siteSettings.SiteRootEditRoles.LastIndexOf(listItem.Value + ";") > -1))
                        )
                    {
                        listItem.Selected = true;
                    }

 

                    if (
                        (pageSettings.EditRoles.LastIndexOf(editItem.Value + ";") > -1)
                        || ((isSiteEditor) && (siteSettings.SiteRootEditRoles.LastIndexOf(listItem.Value + ";") > -1))
                        )
                    {
                        editItem.Selected = true;
                    }

 

                    if (
                        (pageSettings.DraftEditOnlyRoles.LastIndexOf(draftItem.Value + ";") > -1)
                        || ((isSiteEditor) && (siteSettings.SiteRootDraftEditRoles.LastIndexOf(listItem.Value + ";") > -1))
                        )
                    {
                        draftItem.Selected = true;
                    }

 

                    if (
                        (pageSettings.CreateChildPageRoles.LastIndexOf(childItem.Value + ";") > -1)
                        || ((isSiteEditor) && (siteSettings.SiteRootEditRoles.LastIndexOf(listItem.Value + ";") > -1))
                        )
                    {
                        childItem.Selected = true;
                    }

 


                    chkListAuthRoles.Items.Add(listItem);
                    chkListEditRoles.Items.Add(editItem);
                    chkDraftEditRoles.Items.Add(draftItem);
                    chkListCreateChildPageRoles.Items.Add(childItem);
                }
}

 


Q1: Why are these selected when an Admin or Site Editor edit page permissions? Once I understand the intended purpose of forcing them to be checked, maybe they should be disabled, so that they can't be unchecked, thus modifying the database?
Q2: Since all of our roles were defined in the root site before a child side was created, the list of roles to choose as Site Editor are the default ones.  SiteSettings.aspx.cs uses selectedSite to get a list of roles to display.  I think it would make sense to check if UseRelatedSiteMode is enabled and display roles from the site specified by the RelatedSiteID key maybe?


Also, "Roles Not allowed to edit feature instance settings" is not being enforced.  I was able to reproduce this on the demo site as well.  Take a look at the Permisssions Test page and test user.

 

11/5/2011 11:03:43 AM
Gravatar
Total Posts 18439

Re: Admin View Permissions & Child Pages Site Map

Hi,

To be honest I don't know why it has this kind of thing for selection logic:

  || ((isSiteEditor) && (siteSettings.SiteRootEditRoles.LastIndexOf(listItem.Value + ";") > -1))

I probably had some reason for doing that at some point but it seems incorrect today. I've commented that part out and committed to the repository. I also fixed a bug in the parent page dialog which was not showing any pages for site editors in child sites.

I've got a family event the rest of the day but tomorrow I will do some thorough testing on the scenario of related sites mode and child site editors and look for any other things that are not working as expected. I admit I'm not using related sites mode in any of my own sites so it has not been something I've been testing frequently and is overdue for some review.

Q2: Since all of our roles were defined in the root site before a child side was created, the list of roles to choose as Site Editor are the default ones.  SiteSettings.aspx.cs uses selectedSite to get a list of roles to display.  I think it would make sense to check if UseRelatedSiteMode is enabled and display roles from the site specified by the RelatedSiteID key maybe?

Roles are consistently used in all cases in related sites mode as far as I know because with related sites mode enabled the Role.GetSiteRoles method is using the related site id no matter what site id is passed in.

public static IDataReader GetSiteRoles(int siteId)
{
        if (UseRelatedSiteMode) { siteId = RelatedSiteID; }

        return DBRoles.GetSiteRoles(siteId);
}

Best,

Joe

You must sign in to post in the forums. This thread is closed to new posts.