Extension talk:AccessControl

57 previous topics.

Archives

Wikitext archive (AccessControl)

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

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.

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!

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

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

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

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?

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

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?

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.

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!

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

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.

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.

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

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!

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"

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.

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.

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

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

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.

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.

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

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?

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.

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.

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

Hi, is there a way to use this extension together with "confirmaccount" extension? I have the problem that I can not access the confirmation Link. For example: myexamplewiki.de/index.php?title=Spezial:Benutzerkonto_beantragen&action=confirmemail&wpEmailToken=8f81128ed84b44d1e69caf8e65c381b1 I only get redirekted to access_denied page. The specialpage "Benutzerkonto_beantragen" is accessible for anonymous.

Thank you in advance ;-)

Yes. My wiki use Extension:ConfirmAccount and Extension:ConfirmEdit for captcha. First must be set $wgAutoConfirmAge . It's code from my LocalSettings.php file:

$wgGroupPermissions['autoconfirmed']['createpage'] = true;
$wgAutoConfirmAge = 6000;

and rights for namespaces:

$wgNamespaceProtection[NS_MAIN]      = array( 'autoconfirmed' );  //$wgNamespaceProtection[NS_MAIN_TALK] = array( 'autoconfirmed' $wgNamespaceProtection[NS_USER]      = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_SPECIAL]   = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_FILE]      = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_MEDIAWIKI] = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_TEMPLATE]  = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_HELP]      = array( 'autoconfirmed' ); $wgNamespaceProtection[NS_CATEGORY]  = array( 'autoconfirmed' );

Bellow is registration load Extension:ConfirmAccount

wfLoadExtension( 'ConfirmAccount' );
$wgConfirmAccountContact = "admin@mywiki.domain";
$wgConfirmAccountCaptchas = true ;
$wgConfirmAccountRequestFormItems['Biography']['minWords'] = 15;

And now is part for Extension:ConfirmEdit (protection for bots)

wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]);
$wgCaptchaQuestions = [
// "What is the capital of Spain" => 'MADRID', // Answers are case insensitive
"What is the name of this wiki?" => $wgSitename, // You can use variables
// "How many fingers does a hand have?" => [ 5, 'five' ], // A question may have many answers
];
$wgMainCacheType    = CACHE_ANYTHING;
$wgCaptchaTriggers['edit']          = false;
$wgCaptchaTriggers['create']        = false;
$wgCaptchaTriggers['createtalk']    = false;
$wgCaptchaTriggers['addurl']        = false;
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['badlogin']      = false;
// This code solve confirmation e-mail address
$wgHooks['LocalUserCreated'][] = 'onLocalUserCreatedEmailAutoConfirm';
function onLocalUserCreatedEmailAutoConfirm( $user, $autocreated ) {
   $user->confirmEmail();
   $user->SaveSettings();
}

Please note that email confirmation is not needed, so it was necessary to edit the text of the message for email which is sent to account applicants.

"Please note that email confirmation is not needed" how can I disable the confirmation Email? I have set $wgEmailAuthentication = false; but still the mail is send and I can not use the confirmation Link.

OK, now I understand, the email gets send but I have to change the text to something like "You have created a wiki account and will soon receive a email with logindata" I see that I have the request alrady on the specialpage to confirm the account. But I dont get an reminder Email that there is a new Account waiting. With confirm Email working, I always got an email that an account is ready to confirm.

$wgConfirmAccountContact = "myreminder@email.whatever"

Is there a way to receive a email and use your solution? Otherwise i have to remind me myself to look sometimes for new accounts.

The Extension:ConfirmAccount has its problems. For example unsupport of the multilanguage wiki. I solve it by own system messages, which has content in main languages used on my wiki (english, polish and czech). Go to Special:AllMessages, in your wiki and find messages 'emailuserfooter', 'confirmaccount-email-body5', 'confirmaccount-email-body3', 'requestaccount-email-body'

I understand that it is annoying for you not to receive emails notifying you that an account is pending approval. But on the other hand, remember that this application is being frequently filled out by bots. If sending those alert emails were allowed, it would mean they would be spamming your bureaucrats' accounts.

At least this way the bureaucrats have a reason to check the status of the queue of pending applications from time to time. From my point of view, the extension Extension:ConfirmAccount should be rework by maintainer. To show bureaucrats notifications instead of sending emails.

If you want this functionality, enter it as a task in Phabricator, and I'll support your task. Currently I already maintain two extensions that I am working on intensively, although it is not my job. So don't get mad, but someone else has to program this functionality into the ConfirmAccount extension. Sorry.

First, I want to thank you and all the other contributors to extensions and mediawiki. I will use your solution provided bevor. I can understand your way of thinking to have all massages inside of mediawiki. In our environment we have a lot of systems and we decided to have all Information and critical massages in MS Teams so we grab the emails from AccountConfimation and other Systems and reroute them with MS PowerAutomate to special MS Teams channels. With this solution we have all relevant Data at one place for the whole Team. But it is ok to check once a week inside of Mediawiki for new Accounts so keep up the good work and thanks again for your help.

Thank you for your feedback. Unfortunately, this is a functionality that is difficult to test. And as I wrote. The correct solution is notifications, because then it's up to the user if they want to get the message by email as well. Technically, it shouldn't be a problem. See Notifications/Developer_guide . However, my experience with notifications is not yet enough to make a patch for the Extension:ConfirmAccount that would do this. The current solution is simple because it doesn't add a dependency on the Echo extension, but as I've written before, it can be a source of spam.

But it's a good reminder and I'd be very happy to hear about your experience. I don't know if you have read the original manual in English. You should definitely do so, as it also describes possible risks and solutions to specific situations. The Extension:AccessControl is based on the fact that wiki content is created by responsible users who have no interest in doing harm.

Hi, I installed this extension on my private wiki. It's working only if I add just 1 group within <accesscontrol> tag but if I add more groups e.g. <accesscontrol>group1, group2, group3</accesscontrol> it's not working and blocking the page with a message that "his page contains copyright protected text..." so is there a bug? and how to fix it?

*MediaWiki 1.39

*PHP 7.4

*AccessControl 5

Thank you

I am sorry, but version 5 isn't my provenience. I use branch form-support and new syntax. See AccessControl

Thank you for replying. I don't know whom to ping in this case because the version 5 seems to have many flaws. If I add just 1 group within the accesscontrol tags it works and show the page to users in that group but still they are not able to edit the page because as soon as I activate the extension the edit option disappear for everyone and I have no idea how to fix it.

In my original version, the colon in the name of the user list was important. It was not a namespace separator. There might be a problem with that, because later modifications led to making it a namespace delimiter.