• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 4.x Series
    • Bug
    • Users can no longer edit?

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: Users can no longer edit?

    • Issue Tools
      • View Changes
    1. issueid=4267 March 30, 2015 3:46 PM
      beernuts beernuts is offline
      Junior Member
      Users can no longer edit?

      Upgraded to 4.02 from 4.01 and now all of a sudden our users can't edit the wiki. I checked the usergroup permissions and they look fine to me. Did something change in the upgrade that would cause this? I haven't seen anything about it if so.
    Issue Details
    Issue Number 4267
    Issue Type Bug
    Project VaultWiki 4.x Series
    Category Permissions / Security
    Status Fixed
    Priority 3 - Loss of Functionality
    Affected Version 4.0.2
    Fixed Version 4.0.2
    Milestone (none)
    Software DependencyAny
    License TypePaid
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. March 30, 2015 4:04 PM
      pegasus pegasus is offline
      VaultWiki Team
      I would need a link to a page, but in general, no there has not been a change that would affect ability to edit directly.

      There were some changes regarding article protection -- article protection was not correctly applied in all cases in 4.0.1. It is possible that users are not able to edit protected articles now if they do not have permission to lift protection -- which is the expected behavior.

      That is what comes to mind initially. Again, I would have a better idea if you linked to a page that users are unable to edit.
      Reply Reply
    2. March 30, 2015 4:53 PM
      beernuts beernuts is offline
      Junior Member
      Users can't edit any page that they used to be able to. They can't even edit their user pages.

      Obviously something changed because all we did was upgrade VW. No usergroup changes have been made.
      Reply Reply
    3. March 30, 2015 10:50 PM
      pegasus pegasus is offline
      VaultWiki Team
      I've looked through the changesets for the past 2 months and there have been no changes to how permissions for the Edit tab are calculated, except for a change to protection so moderators can edit articles even if the article creator says no one can (to prevent an irremovable lock). Since it sounds like your issue occurs across the whole wiki, it's unlikely this change is related.

      It might just be that you need to edit a usergroup again and click save even if you don't make any changes. I don't know why but sometimes this works.

      Related, I did notice that the upgrade script for 4.0.2 is supposed to "fix" permissions sets that might have been orphaned in previous versions (and were being ignored). This upgrade script does not erase any existing permissions, but rather re-applies permissions that the database forgot were already there. If you had orphaned permissions that were different from what you and your users have come to expect, you can have the behavior you experience.

      You will want to look at the following types of permissions to verify you don't have renegade "No" or "Never" values in effect. The orphan fix affects the following:
      • Global Usergroup permissions from VaultWiki 3 for usergroups for which you have not changed permissions since migrating to VaultWiki 4.
      • User-level Access Masks that were applied to "All Areas" rather than just one area.
      • Custom Moderator Permissions that were applied to "All Areas" rather than just one area.

      These are the only changes I'm aware of that relate to permissions for the Edit tab in any way (there were changes to permissions for other tabs to improve security, but they should not affect Edit).

      I'm aware of random memory collisions and other issues for sites using VaultWiki 4 with some builds of PHP 7 (experimental version of PHP). If you're using PHP 7, you might want to consider rolling back to PHP 5.6 until we declare full compatibility. Perhaps the memory collisions are affecting permissions.

      If your issue persists, you may have to submit another Support Ticket so that we can try to figure out what happened. No one else has reported an issue like this for 4.0.2.
      Reply Reply
    4. April 1, 2015 11:45 AM
      beernuts beernuts is offline
      Junior Member
      I don't see any "Never" permissions set anywhere, so I'm still stumped. How do we submit a private support ticket?
      Reply Reply
    5. April 1, 2015 12:01 PM
      pegasus pegasus is offline
      VaultWiki Team
      Use this link: https://www.vaultwiki.org/members/?d...e&productid=20

      Which is available at any time under Members > Services > Free Services > Ticket Support, any time you feel a private ticket may be needed. If any fields are not applicable for your installation or you are not ready to fill them in, feel free to submit fake values for those fields for the time being.
      Reply Reply
    6. April 1, 2015 3:03 PM
      pegasus pegasus is offline
      VaultWiki Team
      Turned out to be a scoping problem. It resulted in some usergroups being treated as if they were the banned group. In vault/core/model/permissions/vb3.php, find:
      Code:
      if ($tmp === null)
      Before it, add:
      Code:
      global $vbulletin;
      Not the case in your installation, and probably in no one's installations, but if:
      • A user is not banned, AND
      • A user has an ignored usergroup with "Never" permissions, AND
      • The user also has an unaffected usergroup with "Yes" permissions for the same action.

      This constitutes use of the "Never" permission contrary to its designed intent; however, it could possibly raise a permissions escalation vulnerability since the "Yes" on the unaffected usergroup will no longer be ignored. Note that this is not a vulnerability that users can "exploit." Thus there is no harm in leaving this issue public.

      I am issuing a Patch Level release to correct this issue because there is potential for permissions escalation.
      Reply Reply
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 6:08 PM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2025 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2025 DragonByte Technologies Ltd.
    Copyright © 2008 - 2024 VaultWiki Team, Cracked Egg Studios, LLC.