Extension talk:AccessControl/2020
This page used the Structured Discussions extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made. |
57 previous topics.
![]() Archives
|
---|
|
Previous discussion was archived at Extension talk:AccessControl/Archive 1 on 24 October 2016.
AccesControl and VisualEditor
RESOLVED | |
Code change shipped with version 3.0.1 |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
It seems that in AccessControl, a user in Read Only mode can successfully edit a page with the VisualEditor even if the History and Edit option are not available.
I found out a way to solve the problem. What is happening is that VisualEditor wgAction is "view" and not "edit" (see here), this means that it bypass the $wgAction['edit'] = false
block. VisualEditor use a custom action named veaction
instead. To counteract this I modified the following this bit of code in the userVerify()
function:
if ( $rights[VIEW][$wgUser->mName] ) { return true; } else {
to the following:
if ( $rights[VIEW][$wgUser->mName] ) { if ( $wgRequest->getText( 'veaction' ) ) { return self::doRedirect( 'accesscontrol-redirect-users' ); } else { return true; } } else {
This stop the user from going with the &veaction=edit. However, one of the problem is that the "Edit" tab still allows access to the VisualEditor (but block access to the WikiCode Editore). I don't understand exactly why but the workaround for this is the remove completely the Edit tabs for those in ReadOnly mode. You may also remove the Edit link on each header (if this is activated in the option), since they are useless. The easiest, but probably non-elegant, way to do this was to modify the readOnlyUser()
function to add $wgOut
to the global
and the following at the end of the if ( ! $wgReadOnlyUser )
block (before $wgReadOnlyUser = true;
for example):
$wgOut->addInlineScript( "document.getElementById('ca-history') && document.getElementById('ca-history').parentNode.removeChild(document.getElementById('ca-history'));" );
$wgOut->addInlineScript( "document.getElementById('ca-edit') && document.getElementById('ca-edit').parentNode.removeChild(document.getElementById('ca-edit'));" );
$wgOut->addInlineScript( "document.getElementById('ca-ve-edit') && document.getElementById('ca-ve-edit').parentNode.removeChild(document.getElementById('ca-ve-edit'));" );
$wgOut->addInlineScript( "Array.from(document.getElementsByClassName('mw-editsection')).map(element => element.parentNode.removeChild(element));" );
The first three lines remove the Edit tab and the History one (since it is blocked anyway). The last line remove the Edit direct link from the header. This will block the use from going through internal page link and direct address. HtheChemist (talk) 16:18, 4 February 2020 (UTC)
- Hello @HtheChemist, thanks a lot for this patch, are you planning to ask the creator of the extension (@Want ) to merge it in the official release ?
- Version tested AccessControl 3.0 (5f9451a) 16:34, 1 July 2019 and MediaWiki 1.34.0 Nicolas NALLET Wiki-Valley.com (talk) 11:20, 24 February 2020 (UTC)
- I honestly never though of it. However I don't thing the git is open. I have forwarded the information to him, maybe he will include it in a next release.
- HtheChemist (talk) 16:39, 19 March 2020 (UTC)
- Nicolas write to me, and new commit into git to version 3.0.1 is based on your propose. Thank you. Want (talk) 11:19, 27 May 2020 (UTC)
Hide specific page except to owner?
Hi @Want thank you for the great extension.
I wanted to ask you if AccessControl or another method would allow me to do the following.
- Someone creates a page. That page is automatically ONLY visible to the owner (hidden from anyone else) but the owner can also invite others to see the page.
- Only the owner (original creator) can edit the page, but they can allow others to edit it if they want.
- The owner can choose to publish the page (make it publicly visible)
- If they make they publish the page, the revision history of when it was private does not show, instead the revision history is reset and starts anew for the public version.
Please let me know, thank you. MavropaliasG (talk) 10:39, 26 February 2020 (UTC)
How to use the Template variant?
Hi, putting < accesscontrol >ConfidentialUsers</accesscontrol >
to a page protects it for every user who is not on the Page "ConfidentialUsers". -->Works
I made a Template : Accesscontrol with the content:
<accesscontrol>ConfidentialUsers</accesscontrol>The Page { { PAGENAME } } is protected. The following persons have access: { { { 1 | } } }
Adding { { Accesscontrol | Admin, TestUser } }
and opening the Page to be protected with even anonymous user gives me "this is a protected page" but i can read everything. Bobbythemoh (talk) 10:23, 28 March 2020 (UTC)
- accesscontrol need to be all in small cap like this { { accesscontrol | } } HtheChemist (talk) 14:02, 3 April 2020 (UTC)
- Hey thanks for the reply. Creating "Template : accesscontrol" corrects the Template to "Accesscontrol". There is no change in behavior, it still tells me that the page (red small letters, "THIS PAGE IS PROTECTED") is protected but does not protect it. Bobbythemoh (talk) 07:19, 19 April 2020 (UTC)
Cloning does not work
RESOLVED | |
Cloning works great again. |
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
git clone https://www.thewoodcraft.org/pub/wiki/accesscontrol.git AccessControlgives me "Clone to 'AccessControl' ...
error: Unable to get pack index https://www.thewoodcraft.org/pub/wiki/accesscontrol.git/objects/pack/pack-77aeca7cbb0ce9687eff67103870e76fdaf5a9de.idx" [[kgh]] (talk) 15:53, 10 April 2020 (UTC)
- Any comment? Did I miss something? [[kgh]] (talk) 09:07, 2 June 2020 (UTC)
- This works now, what about you? @Kghbln Kizule (talk) 13:13, 4 November 2020 (UTC)
- Affirmative. Works now! Cool. [[kgh]] (talk) 15:59, 4 November 2020 (UTC)
PHP Notice and Warning
- Setup
- MediaWiki 1.31.7
- AccessControl 3.0
- PHP 7.0.33-0+deb9u7 (apache2handler)
- Issue
PHP Notice: Use of undefined constant PREG_UNMATCHED_AS_NULL - assumed 'PREG_UNMATCHED_AS_NULL' in /../w/extensions/AccessControl/AccessControl.hooks.php on line 647 PHP Warning: preg_match() expects parameter 4 to be integer, string given in /../w/extensions/AccessControl/AccessControl.hooks.php on line 647
[[kgh]] (talk) 08:59, 12 April 2020 (UTC)
- Any comment? Did I miss something? [[kgh]] (talk) 09:07, 2 June 2020 (UTC)
- You have still this problem? Want (talk) 16:39, 17 August 2020 (UTC)
- Ping. Kizule (talk) 18:50, 4 November 2020 (UTC)
- I have no idea how I got this. Pretty bad issue report. Since I did not upgrade any of the software since I reported and no new version of AccessControl is available ... [[kgh]] (talk) 09:33, 5 November 2020 (UTC)
AccessControl and page with a lot of templates (Error 500)
Extension was just downloaded and enabled in LocalSettings.php - no pages were configured to use AccessControl.
I tried to use AccessControl 3.0 with Mediawiki 1.33.1 and have problem with pages that have a lot of templates.
When user tries to access such page it ends up with 500 Internal Server Error and my php error log says:
Got error 'PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in /var/lib/mediawiki/includes/libs/rdbms/database/DatabaseMysqlBase.php on line 743PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0
When i try to increase memory_limit in php.ini file i got timeout, when i increase timeout value i got memory exhausted again and so on.
When i disable plugin page renders immediately.
212.20.106.98 (talk) 07:59, 2 June 2020 (UTC)
New template method
There is a new template method documented in the Czech manual that replaces the old <accesscontrol> tag method. You use the new method as below.
{ {Template accesscontrol | user1, user2, group1 } }
The template doesn't have to actually exist, but it needs to have the string "accesscontrol" in it. In the template you can put something like { {PAGENAME} } to the following users: { { 1 } }. InnerCitadel (talk) 00:31, 2 August 2020 (UTC)
Can AccessControl 3.0 be forked from the old version?
https://github.com/wikimedia/mediawiki-extensions-AccessControl still refers to the old version. On the project page under "Issues" are links to Open tasks and bug reports. Is that the old version or the new?
I personally still use the old version of AccessControl because the new one did not meet my needs. In my testing I found some pages exposed that should have been private, and access to search results restricted, when they should have been public. This page makes it seems like the old version is still supported when it may not be. It's hard to know since the documentation has been merged. I suggest some kind of fork to allow these projects to go their separate ways. T0lk (talk) 00:40, 3 September 2020 (UTC)
- Just want to give an update. I installed the new AccessControl again and tested it. I was able to access a protected page when:
- $wgAccessControlRedirect = false; is set.
- and this api is called: api.php?action=query&prop=revisions&titles=Restricted_Page_Title&rvslots=*&rvprop=content&formatversion=2
- Therefore $wgAccessControlRedirect must be set to true. This exists in the old version of AccessControl too. Probably since MediaWiki 1.32 when Manual:$wgEnableAPI was removed. T0lk (talk) 03:55, 10 September 2020 (UTC)
- Variable $wgAccessControlRedirect is only for development or testing. Not for production using! Want (talk) 18:44, 5 November 2020 (UTC)
- That has never been made clear on the extension page. A note should be added in that case. T0lk (talk) 20:50, 5 November 2020 (UTC)
- I just updated that comment in the PHP example. Eidsjehg (talk) 15:55, 7 December 2022 (UTC)
- With the new version, how do you let anonymous editors edit pages which have no access restrictions? T0lk (talk) 04:15, 11 September 2020 (UTC)
- @Want: Hello, can you respond on this? Kizule (talk) 16:59, 3 November 2020 (UTC)
- I have sponsored the development of a new version of AccessControl myself. Two developers reviewed the code on thewoodcraft.org and advised me not to use it.
- The new version is a complete rework of the original. It introduces a cache for performance, optionally allows searching of content that is restricted, allows editing pages if no access restriction is in place, removes the problem redirect I posted about above and introduces a check to ensure the page in the accesscontrol tag exists. It does not support templates because the original version did not.
- See: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AccessControl/+/627603
- I think thewoodcraft.org version should be forked to a different extension page as now the original code has been updated. Perhaps [[Extension: Template based AccessControl]] T0lk (talk) 17:11, 3 November 2020 (UTC)
- Code of extension was reworked for using with extension Form to need Semantic wiki. Code of extension was reworked for using with extension Form to need Semantic wiki. Completly manual is only czech version, sorry. Want (talk) 18:51, 5 November 2020 (UTC)
- It sounds like your new version is significantly different from the old accesscontrol. T0lk (talk) 20:51, 5 November 2020 (UTC)
- I am sorry, but from spring I have more work with high priority. Code of extension was on last Wikimedia Hackaton completly reworked. It's not continue of version 2.6. You tryed version 3.0 or 3.0.1? Want (talk) 18:39, 5 November 2020 (UTC)
- Hello @Want, @T0lk wants to say that we have different versions of same extension on Gerrit and on "your site". It is confusable, and he wants the current version to be in one place, not in multiple places with different versions. Kizule (talk) 19:02, 5 November 2020 (UTC)
- My suggestion is @Want moves his code to a new extension page, like [[Extension:Template based AccessControl]] or something else. That way the update to AccessControl I have sponsored can be released on gerrit for people who don't need templates to control pages.
- Either that or the code on the thewoodcraft.org should really be merged into gerrit and I can fork the version I'm using to a different extension page. T0lk (talk) 20:53, 5 November 2020 (UTC)
- As an extension author, I prefer you to make a fork and create your own extension. The problem is that I don't know how to get the version 3.0.1 code into the master branch, because in the meantime changes were made to the 2.x code that were not in my original version. And this do complicate merge for me. For it I add info and link to code in my git repository.
- But more than to, is problem with translation of documentation. For me its not priority, but without documentation is not simple understand, how to functioned. And I can't do support for version what I don't use. Want (talk) 18:42, 6 November 2020 (UTC)
- ok, thanks T0lk (talk) 21:06, 6 November 2020 (UTC)
- I hope, that is not very complicated for you. I would definitely pleased, if you to be so kind as to write me, why your developers advised you to not use version 3.x code, because this version solve more unvisible problems. In example fulltext search. Old version do deny access to all results if is searching pattern on any protected page, which has user can't allow access. Version 3.x filter protected pages from list and return results. Want (talk) 09:23, 7 November 2020 (UTC)
- I can't find the conversation from the first, Dec 2019, we were investigation why visual editor allowed anonymous users to edit pages but they couldn't edit using the standard form. There were other strange results which led me to abandoning the update. Here is the comment from the second when asked about it:
- "there are unused or uninitialized variables, some strange code that uses global constant and variables when it is better to use local ones... and generally the extension does not follow architecture principles, uses not clear function and variable names. It makes harder to understand the source code and find bugs there"
- Generally your extension affects pages and users it shouldn't, eg anonymous users may not be able to edit or view history of pages that are not access restricted, this doesn't make sense. The rewrite I sponsored allows anonymous edits to pages that are not access protected, adds a cache for performance, removes the redirect, allows search results to be seen or hidden by configuration, and adds a warning if the page controlling the access doesn't exist.
- I am having my rewrite expanded to include the ability to check out restricted pages like a library book, and will release it as a new extension here when finished. T0lk (talk) 22:09, 8 November 2020 (UTC)
- Hello @T0lk - Did you manage to release your extension? The accesscontrol is not working with mediawiki 1.36.2 and semantic mediawiki. I keep getting witht the current accesscontrol extension:
- I'm not sure if @Want as addressed this all. TazzyTazzy (talk) 07:26, 1 November 2021 (UTC)
[7bfb0b90b17327d8742aa75e] /Layout:TazzyTazzy/Wires InvalidArgumentException: The given PageIdentity does not represent a proper page Backtrace: from /var/www/mediawiki1362/includes/page/WikiPageFactory.php(59) #0 /var/www/mediawiki1362/includes/page/WikiPage.php(211): MediaWiki\Page\WikiPageFactory->newFromTitle() #1 /var/www/mediawiki1362/extensions/AccessControl/AccessControl.hooks.php(946): WikiPage::factory() #2 /var/www/mediawiki1362/extensions/AccessControl/AccessControl.hooks.php(408): AccessControlHooks::getContentPage() #3 /var/www/mediawiki1362/extensions/AccessControl/AccessControl.hooks.php(408): AccessControlHooks::allRightTags()
- I am sorry, but I don't use MediaWiki version 1.36 (stable) but LTS version 1.35.2 I know nothing about your wiki for analyze your problem. Your problem is probably on line 941. MediaWiki from 1.35.4 (and 1.36.2) has changed object Title, which is need for creating new articles. Want (talk) 12:54, 18 November 2021 (UTC)
- You try, please, change in your file
AccessControlHooks.php
line 941, from code $gt = Title::makeTitle( $ns, $title);
- on code
- if resolve your problem, or not. Want (talk) 13:03, 18 November 2021 (UTC)
$gt = Title::makeTitleSafe( $ns, $title, $fragment= '', $interwiki= '');
- This code isn't usable for me for now, because my wiki use the extension Extension:TreeAndMenu, and after change it occured as error. May be actualisation resolve this problem, but I don't time for now. Want (talk) 13:50, 19 November 2021 (UTC)
- No, it's not compatible with the AccessControl extension listed here. The version I'm using is listed here. Since then I've had a checkout extension created to allow people to press a button to gain access to a restricted page. That access can be available to any user, or only users in a specific list. T0lk (talk) 06:26, 7 November 2021 (UTC)
- Yes. Version 3.0 had a problem with Visual Editor. I don't use it on my wiki, so I didn't know about it. But Nicholas contacted me, and version 3.0.1 has fixed it.
- I've also come up with a good way to preserve your code and mine. We can implement your code into the master branch, which continues the existing changes, and I will create a new branch for version 3.x. Want (talk) 13:04, 9 November 2020 (UTC)
exists something like <accesscontrol>all(ro),group1<accesscontrol>
I want to make some pages readable for all users and anonymous users, but only editable by one group, for example IT. Bittnerly (talk) 13:37, 11 December 2020 (UTC)