Extension talk:AccessControl

About this board

57 previous topics.

Archives 

Previous discussion was archived at Extension talk:AccessControl/Archive 1 on 2016-10-24.

Problem related groups and add reading access to non-registered users for certain pages.

4
Nctuser (talkcontribs)

We have installed the lastest (v6.0/2023-03-01) AccessControl extension into our MediaWiki (v1.39.3, PHP v7.4.33), and we have a question about usage realted to groups and the right strategy in our situation.

Our purpose is create three levels of access. First is public where, the non-registered users (anonymous visitors) can read certain pages. We would like create two user groups (both registered), a "staff" group which access (can read) most of (but not all) pages, and a "devteam" who can read, create, edit the restricted technical documentations (this pages should be accessible only for the "devteam" group). We think we can create this construction with help of AccessControl extension but we have stumbled a problem what we have could not to solve.

We put this into the protected page:


{ { AccessControl

| readOnlyAllowedUsers = TestUser

| editAllowedUsers = TestUserAdvanced

} }


In the template above the non-registered users can not see the page, the TestUser can read only but not edit, the TestUserAdvenced can see and edit the page. This works well and this is the expected behavior. But when we translate this to groups the protection does not work as before.

We want apply the schema above and we put this into the protected page:


{ { AccessControl

| readOnlyAllowedGroups = TestUserGroup

| editAllowedGroups = TestUserAdvancedGroup

} }


The TestUser is member of the TestUserGroup group and the TestUserAdvanced is member of the TestUserAdvancedGroup group so we expect the exactly the same behavior as before, but this happens: both the TestUser and TestUserAdvanced cannot see the page and only the administrator can see and edit the page. So the it looks like the group based access control does not work properly.

What can cause this behavior? Is there special rights what needed for the groups to work as before (when we use users in the template)?

Can we put any name instead of AccessControl into the template or has this name special meaning? Can we make this invisible on the page (now "Template: AccessControl" text appears at the top of page)?


For non-registered users we enabled the reading, as in the documentation is shown. But we afraid if the editor non limits (forgets to limit) the access for the page of confidental information will be available for all the non-registered users, so we disabled the reading by default for non-registered users. We thought this will be safer, but we do not know how can we make certaion pages "public". If the visitors reading access is diabled ($wgGroupPermissions['*']['read'] = false;), is there a way to the page creator/editor to make the edited page "public" (available for reding for non-registered users)?


Thank you for yor answer.


We are newbies in MediaWiki and in AccessControl, so sorry, if the question is basic, or already answered in the documentation.

Nctuser (talkcontribs)

On AccessControl extension's wiki page there is a warning which I think supposed to mean that the wiki user groups are not usable any more. However in the "Using" section the editAllowedGroups and readOnlyAllowedGroups keywords are still listed as if they work. Correct me if I am wrong or a confirmation would be nice.

For version ≥ 2.0

MediaWiki versions: 1.18 – 1.20
Warning: From version 2.0 the extension does not use wiki user groups (except sysop), only groups created by user access lists!
185.25.193.185 (talkcontribs)

I also had the same problem, and the documentation is difficult to understand.

I got it working by doing the following:

  • Create a page, e.g. "Department:IT" (it should contain a column, otherwise it won't work)
  • Insert a * Marcus Aurelius inside the page
  • In the page that you want to protect, insert:
    • {{AccessControl | readOnlyAllowedGroups=Department:IT}}
  • Now Marcus Aurelius will be able to read the page, Admin will be able to edit the page, everyone else won't read nor edit the page
Hpyjoy (talkcontribs)

How do you protect the new page you created: "Department:IT". If someone gets the link, they could add themselves to the list.

Reply to "Problem related groups and add reading access to non-registered users for certain pages."

In need of better examples for the "new" way.

1
Hpyjoy (talkcontribs)

I am seeing syntax like this:

{ { AccessControl

| editAllowedUsers = John Doe, Jane Doe

} }

or

{{Warning

| 1 = This page is protected

| editAllowedUsers = John Doe, Jane Doe

}}

In both instances a reference is being made to either template "AccessControl" or "Warning". What are the contents of these templates?

I looked at the original documentation after converting it to English using ChatGPT, but it really doesn't show an example of this template either.

This is what I have tried... and it is not working. I am using mediawiki groups due to users being assigned to one of these group when they login using simplesamlphp and plugableauth extensions. Our organization is TOO BIG, to manage list of groups manually.

<includeonly>

{{AccessControl

| 1 = This page is protected

| isProtectedBy = sysop, bureaucrat, suppress

| editAllowedGroups = bureaucrat

| readOnlyAllowedGroups = suppress

}}

</includeonly>


I created an empty "AccessControl" template since the docs do not show what should go in it. Can someone help?

I have requested access to their sample wiki in the hopes of seeing how they are getting it to work.

Reply to "In need of better examples for the "new" way."

Special pages and group list

1
Jehy (talkcontribs)

Hi! Thanks for your hard work, I was able to use itto upgrade from mediawiki 1.23 and custom fork to upstream :)

But I had to fix two bugs to make it compatible:

  1. https://github.com/wod-serial/AccessControl/commit/3f7e51a432943bb1f5d95f484fae89a338b88503 - page can start with accesscontrol tag, so we should not check it list is the first thing on the page. Also, list syntax supports "*", not only "* "
  2. Special pages became restricted for users after migration to 1.41. I had to make an ugly fix https://github.com/wod-serial/AccessControl/commit/29bd6821041f8819891c72f88fc2f1f2e0257ae4 - can you check compatibility with 1.41?


I added https://phabricator.wikimedia.org/T364369 and https://phabricator.wikimedia.org/T364370 issues for it.

Reply to "Special pages and group list"

protected article is shown after protection-text

1
2A02:810A:1640:18A8:1831:3746:A861:3340 (talkcontribs)

I've installed a new instance of MediaWiki (1.40) with the extension AccessControl. I created an AccessControl Template and the Notification is shown correctly. This is a protected page or you are not allowed to read this.

But in both cases the article is rendered, so you can read the whole content. Can you help me?


{ { AccessControl

| readOnlyAllowedUsers = TestUser

| editAllowedUsers = TestUser

} }

Lorem ipsum dolor sit amet, consectetuer

Reply to "protected article is shown after protection-text"
185.176.161.178 (talkcontribs)

I have installed a fresh MediaWiki 1.39LTS and also using LDAP authentication using the following extensions:


wfLoadExtension( 'PluggableAuth' );  wfLoadExtension( 'LDAPProvider' );

 wfLoadExtension( 'LDAPAuthentication2' );

 wfLoadExtension( 'LDAPAuthorization' );  wfLoadExtension( 'LDAPUserInfo' );

  wfLoadExtension( 'LDAPGroups' );


I have tried various ways but cannot get AccessControl to work using new or old tags.


I have not created any group definitions and any other config, other than getting ldap authentication to work.


Also I want to block all access to certain pages and use accesscontrol to give them read or edit.


Could someone please share some working examples of what needs to be done in a vanilla setup with ldapauthentication

Reply to "LDAP Users"

Error: Call to undefined method User::getUserEffectiveGroups()

9
Edwardando (talkcontribs)

Dear all,

Thanks for the extension, I've had it working previously in a quite a nice way.

I'm doing a new setup with `mediawiki 1.39.3` and the latest AccessControl from git (6.0<).

As soon as I have an <accesscontrol> tag in my page I get the following traceback:


[exception] [b0c1158f01b3bcdf1ce648f1] /index.php?title=MyPage Error: Call to undefined method User::getUserEffectiveGroups()

  1. 0 /var/lib/mediawiki-1.39.3/extensions/AccessControl6/src/AccessControlHooks.php(427): AccessControlHooks::earlySyntaxOfRights()
  2. 1 /var/lib/mediawiki-1.39.3/extensions/AccessControl6/src/AccessControlHooks.php(292): AccessControlHooks::allRightTags()
  3. 2 /var/lib/mediawiki-1.39.3/includes/HookContainer/HookContainer.php(338): AccessControlHooks::onuserCan()
  4. 3 /var/lib/mediawiki-1.39.3/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
  5. 4 /var/lib/mediawiki-1.39.3/includes/HookContainer/HookRunner.php(1965): MediaWiki\HookContainer\HookContainer->run()
  6. 5 /var/lib/mediawiki-1.39.3/includes/Permissions/PermissionManager.php(583): MediaWiki\HookContainer\HookRunner->onGetUserPermissionsErrors()
  7. 6 /var/lib/mediawiki-1.39.3/includes/Permissions/PermissionManager.php(538): MediaWiki\Permissions\PermissionManager->checkPermissionHooks()
  8. 7 /var/lib/mediawiki-1.39.3/includes/Permissions/PermissionManager.php(345): MediaWiki\Permissions\PermissionManager->getPermissionErrorsInternal()
  9. 8 /var/lib/mediawiki-1.39.3/includes/Permissions/UserAuthority.php(259): MediaWiki\Permissions\PermissionManager->getPermissionErrors()
  10. 9 /var/lib/mediawiki-1.39.3/includes/Permissions/UserAuthority.php(205): MediaWiki\Permissions\UserAuthority->internalCan()
  11. 10 /var/lib/mediawiki-1.39.3/includes/user/User.php(3494): MediaWiki\Permissions\UserAuthority->authorizeRead()
  12. 11 /var/lib/mediawiki-1.39.3/includes/MediaWiki.php(227): User->authorizeRead()
  13. 12 /var/lib/mediawiki-1.39.3/includes/MediaWiki.php(904): MediaWiki->performRequest()
  14. 13 /var/lib/mediawiki-1.39.3/includes/MediaWiki.php(562): MediaWiki->main()
  15. 14 /var/lib/mediawiki-1.39.3/index.php(50): MediaWiki->run()
  16. 15 /var/lib/mediawiki-1.39.3/index.php(46): wfIndexMain()
  17. 16 {main}


Am I doing something wrong?

Want (talkcontribs)

What is the content of the accesscontrol element? It's old syntax, before using you must create accesslist, and add the own username minimally.

Edwardando (talkcontribs)

Thanks for the reply, I'm doing something even simpler, I'm trying to restrict the access to a single group:

in LocalSettings.php I have:

$wgGroupPermissions['newGroup']['read'] = true; $wgGroupPermissions['newGroup']['edit'] = true;

and in my access tag I have (at the top of the page):

<accesscontrol>newGroup</accesscontrol>

As soon as I save the page, I have: "Internal error" with the trace shown above. What I'm doing used to work in older versions, I'm pretty sure. Am I doing something wrong?

Want (talkcontribs)

Yes, it's wrong. AccessControl is protection method for common users. Don't work with the any system group. AccessList it's a normal article, where is list of users for allow access to protected page. And 'newGroup' is a title of this page.

Edwardando (talkcontribs)

OK that's clear and that's all working with the old syntax, sorry about the system vs. page-user-group confusion!

Thanks really a lot for the help!

Want (talkcontribs)

It's ok. I know that it may be for newbies complicated from start. Good luck!

QixxDev (talkcontribs)

I also had it working the way you described in the past, but with 1.39+ it no longer worked for me. For the specific error you mentioned, I found that the User class no longer has that method in place, so even if you go for the default solution, I don't think this will work. In the User class, getGroups() provides similar results. So perhaps this can be used?


However, even once this is bridged, we're still with the situation where custom groups are not looked at.


I think I might have a workaround for that, but I'd need to look at the code first.

Want (talkcontribs)

From the start my idee was to make an extension for users, not for administrators or bureaucrats. MediaWiki user groups are designed for a different level of access. And it was complication for code too. It was reason for remove since 2.0 version. But later, when I have problem with my login to gerrit, it was implemented into code by another developers again. But main version not based on their code. And I don't integrate code, which isn't concenate with my idee. I am sorry.

QixxDev (talkcontribs)

I have a workaround. Do you have a pastebox or something where I can share my edits?

Reply to "Error: Call to undefined method User::getUserEffectiveGroups()"

everybody should read protected page

1
Marc19791 (talkcontribs)

Dear all,

I use extension AccessControl. I put in my protected page in the beginning the following code:


{{AccessControl

| 1 = This page is protected

| readOnlyAllowedUser = *

| editAllowedUsers = Testuser

}}


Testuser and Admin can edit page. That's fine.

Unfortunately just Testuser and Admin can read my protected page. So nobody else is able to read my protected page. Is there another command when everybody (anonymous user too) should read protected page instead of "readOnlyAllowedUser = *"


Thanks in advance for your help!

Reply to "everybody should read protected page"
Jusferreira (talkcontribs)

When I access a restricted page, it changes to the page (name of wiki):Deny user. It should stay on the page I want to access and say "This page is restricted"

Want (talkcontribs)

Solution exist, but more fantasy need for it. You need extension parser functions, and template which be apply if protected content. I use it on my wiki for pages which may be accessible for all registered users, but not for anonymous.

Want (talkcontribs)

No. Because AccessControl don't any change in content. Principle of it is interrupt the preparing page process if user not allowed. If page is not redirected, process continue and content is available.

Reply to "Problem"
Edwardando (talkcontribs)

Sorry, perhaps ignore the post below, let's try to use the new features that you have so nicely implemented.

I have added the TemplateData and AccessControl to `LocalSettings.php` extension and made the following template called `Template:AccessControlTemplate`:

< noinclude>

< templatedata>

{

   "description": "Template for permissions",

   "params": {

      "editAllowedGroups": {

         "label": "editAllowedGroups",

         "description": "Wiki groups for editing",

         "type": "string",

         "required": true

      },

      "readOnlyAllowedGroups": {

         "label": "readOnlyAllowedGroups",

         "description": "Wiki groups for read only",

         "type": "string",

         "required": false

      }

   }

}

< /templatedata>

< /noinclude>

< hr>

< p style="text-align:center">This page is protected. Editing groups: { { { editAllowedGroups | None } } } Viewing groups: { { { readOnlyAllowedGroups | None } } } < /p>

< hr>

...from my wiki pages I then declare the template at the top of the page:


{ { AccessControlTemplate | editAllowedGroups=myGroup } }


The nice banner appears on the page ...but users not in `myGroup` can still edit! What's going on?!


Thanks for any help

Want (talkcontribs)

First: It's JSON code, not template code. Second: For setting access is important value of attributes accepted by AccessControl, not template.

Edwardando (talkcontribs)

OK, so the above is wrong? It would be really useful in general to have a minimum working example for the old and new system.

Want (talkcontribs)

Follow the example on the main page of this extension.

  1. Use any page where is any template
  2. Add named attributte editAllowedUsers=
  3. And as value add your own username

After save this change been this page selfprotected by new syntax. And access been allowed only for you. If you unlogged. Page be unavailabled for anonymous access.

Edwardando (talkcontribs)

...looking at the log I'm getting errors from AccessControl:


[error] [5fa5828d64c6df49bb879e83] /index.php?title=MyPage   PHP Deprecated: Use of userCan hook (used in AccessControlHooks::onuserCan) was deprecated in MediaWiki 1.37. [Called from MediaWiki\HookContainer\HookContainer::run]


[error] [5fa5828d64c6df49bb879e83] /index.php?title=MyPage   PHP Deprecated: Use of Title::$mTextform was deprecated in MediaWiki 1.37. [Called from AccessControlHooks::onuserCan]


[error] [5fa5828d64c6df49bb879e83] /index.php?title=MyPage   PHP Deprecated: Use of Title::$mNamespace was deprecated in MediaWiki 1.37. [Called from AccessControlHooks::onuserCan]


[error] [5fa5828d64c6df49bb879e83] /index.php?title=MyPage   PHP Deprecated: Use of $wgUser was deprecated in MediaWiki 1.35. [Called from AccessControlHooks::onuserCan]


[error] [5fa5828d64c6df49bb879e83] /index.php?title=MyPage   PHP Deprecated: $wgUser reassignment detected [Called from AccessControlHooks::onuserCan]


[error] [5fa5828d64c6df49bb879e83] /index.php?title=MyPage  PHP Deprecated: Use of Title::$mDbkeyform was deprecated in MediaWiki 1.37. [Called from AccessControlHooks::onuserCan]


That's a lot of deprecations! Are these the source of the problem? I'm using mediawiki 1.39.3 as suggested on frontpage

Reply to "Use of templates"

Nginx Redirect Not Working

4
Dylan Banta (talkcontribs)

I have applied <accesscontrol> to a page named Quests on my wiki. https://dnd.dylanbanta.com/index.php?title=Quests

The access control tag does seem to work fine, but if you don't have access to the page (Not logged in for example) you get redirected to the following page https://dnd.dylanbanta.com/index.php/The+Luterra+Wiki:Deny_user which doesn't exist (with or without the spaces in the URL) and 404s.

The first thing I've noticed is that the url is constructed differently, so I tried editing my LocalSettings.php and Nginx configurations


Firstly I had to change

$wgSitename = "The Luterra Wiki";

to

$wgSitename = "The_Luterra_Wiki";

to remove the spaces from the url. Now it redirects to

https://dnd.dylanbanta.com/index.php/The_Luterra_Wiki:Deny_user which still 404s but at least the URL won't have spaces.


I wasn't sure if AccessControl expects Short URLs so I changed the LocalSettings.php to include the following

$wgScriptPath = "";

$wgArticlePath = "/wiki/$1";

$wgUsePathInfo = true;


I can now access my Quests page from

https://dnd.dylanbanta.com/wiki/Quests when logged in

and logged out it now redirects to

https://dnd.dylanbanta.com/index.php/The_Luterra_Wiki:Deny_user

which doesn't include the /wiki/ part of the url, and still isn't an existing page.

At this point, I'm pretty confused as to what to do to fix these redirects. I'm using nginx so perhaps I need to configure something with that?

Want (talkcontribs)

Your problem is (by me) very strictly settings. You page Deny_user, which the anonymous user inform about deny access, not exists. It must be allowed for anonyous view.

Want (talkcontribs)

First: Change spaces to undescores, have not sense, because in MediaWiki do for article title automatically. See Manual:Page table

Next: For answer is important information about versions used.

Want (talkcontribs)

Last version 6.0 from git use variable AccessControlMeta. If set true, do redirect to page Deny_user in main namespace.

Reply to "Nginx Redirect Not Working"