Extension talk:AccessControl/Archive 3

57 previous topics.

Archives

Wikitext archive (AccessControl)

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

I'm using the full LDAP stack to authenticate and authorize users with an Active Directory/LDAPS server :

PluggableAuth/LDAPProvider/LDAPAuthentication2/LDAPAuthorization/LDAPGroups

• authentication works fine for myuser@mydomain

• restrict connection to group CN=SG_Digital_IT,OU=org,DC=mydomain,DC=com to which belongs myuser@mydomain works fine, using authorization.rules.groups.required list (we use userprincipalname as user attribute)
• restriction on specific pages to myuser@mydomain works fine But impossible to make it work for LDAP groups. : I have created a local group in LocalSettings.php : $wgGroupPermissions['SG_Digital_IT']['read'] = true; And a mapping in my /usr/share/mediawiki/extensions/LDAPProvider/ldapprovider.json file : "mapping": {        "SG_Digital_IT": "SG_Digital_IT,OU=org,DC=mydomain,DC=com" }

But then in a page, the directive "e‌ditAllowedGroups = SG_Digital_IT" does provide access to the page

When Am I wrong ?

We're upgrading to MediaWiki version 1.39, but the REL1_39 version of the AccessControl gives 2.6 as version (Special:Version-page and extension.json). REL1_40 gives 6.0. Version 2.6 is completely outdated.

I used: git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/AccessControl

How do I get the right version?

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

Hi, have you found a solution for this problem?

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.

AccessControl don't work with the Mediwiki groups. Only sysop allowed for all. I created account on my wiki for you and prepared test page but we must logged first for start autoconfirm interval. -- Want (talk) 13:48, 30 May 2024 (UTC)

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

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

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.

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

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.