Extension talk:AccessControl/2017

57 previous topics.

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

Cannot access Special: namespace with AccessControl enabled

I migrated my wiki (from 1.18 to latest 1.28). I was using the old AccessControl extension. Afer the migration (and updating the AccessControl plugin to the latest) whenever I try to access any of the Special Pages (including UserLogin and UserLogout) I get:

[e77339a315d8aef182f77e7f] /wiki/index.php?title=Special:UserLogin&returnto=Main+Page MWException from line 121 of /var/www/mediawiki-1.28.0/includes/page/WikiPage.php: Invalid or virtual namespace -1 given.

Backtrace:

  1. 0 /var/www/mediawiki-1.28.0/extensions/AccessControl/AccessControl.hooks.php(86): WikiPage::factory(Title)
  2. 1 /var/www/mediawiki-1.28.0/extensions/AccessControl/AccessControl.hooks.php(295): AccessControlHooks::getContentPage(integer, string)
  3. 2 [internal function]: AccessControlHooks::onUserCan(Title, User, string, string)
  4. 3 /var/www/mediawiki-1.28.0/includes/Hooks.php(195): call_user_func_array(string, array)
  5. 4 /var/www/mediawiki-1.28.0/includes/Title.php(2056): Hooks::run(string, array)
  6. 5 /var/www/mediawiki-1.28.0/includes/Title.php(2498): Title->checkPermissionHooks(string, User, array, string, boolean)
  7. 6 /var/www/mediawiki-1.28.0/includes/Title.php(1924): Title->getUserPermissionsErrorsInternal(string, User, string)
  8. 7 /var/www/mediawiki-1.28.0/includes/MediaWiki.php(202): Title->getUserPermissionsErrors(string, User)
  9. 8 /var/www/mediawiki-1.28.0/includes/MediaWiki.php(851): MediaWiki->performRequest()
  10. 9 /var/www/mediawiki-1.28.0/includes/MediaWiki.php(512): MediaWiki->main()
  11. 10 /var/www/mediawiki-1.28.0/index.php(43): MediaWiki->run()
  12. 11 {main}

Can you pls advice me how to properly configure the AccessControl plugin ? 134.76.234.21 (talk) 10:56, 10 January 2017 (UTC)

I also get this error in MW 1.29.0-wmf.3 when going to Special:Version. 132.183.13.75 (talk) 20:58, 11 January 2017 (UTC)
I fixed this one by editing "includes/page/WikiPage.php", in function factory.
On line 120, replace :
} elseif ( $ns < 0 ) {
By :
} elseif ( $ns < -1 ) { 109.190.122.47 (talk) 11:02, 17 January 2017 (UTC)
This worked for me. Thanks DanielJamieson (talk) 12:29, 18 January 2017 (UTC)
Hello,
Same Problem here, please fix it in the code, because at every update the changes ar lost!
Kind regards... 213.164.76.76 (talk) 10:12, 26 March 2018 (UTC)
Another dirty fix:
In file "extensions/AccessControl/AccessControl.hooks.php":
Add(not replace, just add) to line 83 this code:
if ($namespace == -1) $namespace = 0;
It works for me and will not overwritten after wiki core update. 109.233.225.254 (talk) 07:10, 3 April 2018 (UTC)
might be helpful to include the whole line.
so, from this
if ( $gt->isSpecialPage() ) {
to this?
if ( $gt->isSpecialPage() ) {if ($namespace == -1) $namespace = 0;
Johnywhy (talk) 01:06, 26 June 2018 (UTC)

AccessControl and VisualEditor

While AccessControl is enabled, I am unable to use visual editor on a protected page, regardless of the access. Is there a way to only allow VisualEditor to work for sysop and named accounts?

MediaWiki 1.27.1 PHP 5.5.9-1ubuntu4.19 (apache2handler) AccessControl 2.6 (f6c7826) 16:17, 12 December 2016 VisualEditor 0.1.0 (a733545) 21:54, 3 March 2016 DanielJamieson (talk) 12:29, 18 January 2017 (UTC)

MW 1.27-1.28 parsing bug

Running this under MW 1.27.1 I came across a template parsing bug.

On my templates, I include usage instructions in the block. Part of those instructions include the template name inside a block as shown here: <pre><noinclude>'''To use this template, type <nowiki>{{MyTemplate}}</nowiki> on the article page at the top.'''</pre></noinclude> <nowiki></pre>

It appears that the AccessControl template parser reads that as a sub-template and gets caught in an infinite loop, resulting in a 500 error.

I also ran this test on a MW 1.28 install I spun up and get the following error from PHP: Fatal error: Maximum function nesting level of '256' reached, aborting! in C:\wamp\www\mediawiki-1.28.0\includes\Setup.php on line 528

The specific trace:

1	0.0002	133496	{main}( )	...\index.php:0
2	0.1531	11310776	MediaWiki->run( )	...\index.php:43
3	0.1535	11311144	MediaWiki->main( )	...\MediaWiki.php:512
4	0.1678	12662704	MediaWiki->performRequest( )	...\MediaWiki.php:851
5	0.1678	12662952	Title->getUserPermissionsErrors( )	...\MediaWiki.php:202
6	0.1678	12663112	Title->getUserPermissionsErrorsInternal( )	...\Title.php:1924
7	0.1678	12663680	Title->checkPermissionHooks( )	...\Title.php:2498
8	0.1678	12664152	Hooks::run( )	...\Title.php:2056
9	0.1684	12729848	call_user_func_array:{C:\wamp\www\mediawiki-1.28.0\includes\Hooks.php:195} ( )	...\Hooks.php:195
10	0.1684	12730304	AccessControlHooks::onUserCan( )	...\Hooks.php:195
11	0.1744	12900176	AccessControlHooks::allRightTags( )	...\AccessControl.hooks.php:310
12	0.1744	12900648	AccessControlHooks::fromTemplates( )	...\AccessControl.hooks.php:261
13	0.1783	12902904	AccessControlHooks::allRightTags( )	...\AccessControl.hooks.php:194
14	0.1783	12903160	AccessControlHooks::fromTemplates( )	...\AccessControl.hooks.php:261
(continues a while)
237	0.5346	13276128	AccessControlHooks::allRightTags( )	...\AccessControl.hooks.php:194
238	0.5346	13341880	AccessControlHooks::fromTemplates( )	...\AccessControl.hooks.php:261
239	0.5347	13342064	AccessControlHooks::getContentPage( )	...\AccessControl.hooks.php:194
240	0.5347	13345496	WikiPage->getContent( )	...\AccessControl.hooks.php:86
241	0.5347	13345560	WikiPage->loadLastEdit( )	...\WikiPage.php:681
242	0.5347	13345560	WikiPage->getLatest( )	...\WikiPage.php:615
243	0.5347	13345560	WikiPage->loadPageData( )	...\WikiPage.php:563
244	0.5351	13347320	WikiPage->loadFromRow( )	...\WikiPage.php:393
245	0.5352	13347312	Title->loadRestrictions( )	...\WikiPage.php:417
246	0.5353	13347632	WANObjectCache->getWithSetCallback( )	...\Title.php:2984
247	0.5353	13347808	WANObjectCache->doGetWithSetCallback( )	...\WANObjectCache.php:906
248	0.5353	13348856	call_user_func_array:{C:\wamp\www\mediawiki-1.28.0\includes\libs\objectcache\WANObjectCache.php:1004} ( )	...\WANObjectCache.php:1004
249	0.5353	13348928	Title->{closure:C:\wamp\www\mediawiki-1.28.0\includes\Title.php:2970-2983}( )	...\WANObjectCache.php:1004
250	0.5354	13349992	Database->select( )	...\Title.php:2981
251	0.5354	13350152	Database->selectSQLText( )	...\Database.php:1252
252	0.5354	13350760	Database->tableNamesWithIndexClauseOrJOIN( )	...\Database.php:1285
253	0.5354	13351328	Database->tableNameWithAlias( )	...\Database.php:1934
254	0.5354	13351328	DatabaseSqlite->tableName( )	...\Database.php:1811
255	0.5354	13351472	Database->tableName( )	...\DatabaseSqlite.php:425
256	0.5354	13351816	Database->addIdentifierQuotes( )	...\Database.php:1752

TheDrew (talk) 15:35, 11 February 2017 (UTC)

Did a bit more digging and this may not be a bug with AccessControl afterall but a change in MW. I know 2.5 worked in MW 1.24 but in my current MW 1.28 test install, 2.4, 2.5, and 2.6 all error out, suggesting a change in the behavior of MW.
What I have been able to do is introduce a sanity test in the fromTemplates() function which determines roughly how deep we are recursively and kicks out if we get more then 100 calls into the function. TheDrew (talk) 04:40, 7 March 2017 (UTC)

What did I wrongly?

Hi Guys,

I am facing an issue with this extension. Every time I try to access protected webpage with the login mentioned in allowed user group I receive the same error message over again.

I have tried multiple MW versions like 1.28 + AC 2.5 and 2.5.1 and 2.6; 1.27.1 + 2.5.1 and 2.6 but neither one was working and I still receive HTTP ERROR 500.

The only accounts which can access restricted sites are those with administrator privileges.

I would say that it is done thanks to:

$wgAdminCanReadAll = true; // sysop users can read all restricted pages

So this extension is working for me partly.

Could you please help me out as I desperately need this extension to be working? Or do you have any reference for similar extension?

Thank you in advance! 80.95.98.18 (talk) 15:19, 22 February 2017 (UTC)

Extension version 2.5.1 (from me) is not like version 2.6! I do support only for my version, because 2.6 not functioned on servers administrated by me. And I do not have time for debug code of version 2.6 why it. You must write about help to authors of changes. Sorry.
Next. You need find, if extension AC is not in collision with another extension of your wiki which is used.
And last. You have rightly created accesslist? Main difference between my version 2.5.1 and 2.6 - my version NOT USE own namespace for accesslist!! Accesslist is normal article, with colon in the name. It is very important! Wiki engine first time do test, if a page of accesslist is normal page, and after success, is parsed content from page. Want (talk) 14:33, 23 February 2017 (UTC)
I used only articles not namespaces and your version is working fine for me!
Thank you! 80.95.98.18 (talk) 09:18, 24 February 2017 (UTC)
Had the same problem.
|AccessControl
|2.6(4c085e6)
|}
Sites in Namespaces as accesslist didn't work.
But normal article do.
Thank you! PrinzQMP (talk) 09:58, 5 April 2017 (UTC)

AccessControl-tags suddenly need to be case-sensitive?

Hi Guys, I'm baffled by a strange behaviour in AC 2.6 with MW version 1.27.1 with PHP 5.5.14 and MariaDB 10.0.29 I deactivated AC in the previous installs of MW because I couldn't get it to work properly but thought to give it another try with the new update. But when I tried to search for a restricted page I got the following error-message Ungültiger Titel Der angeforderte Seitentitel enthält ungültige Zeichen: „<“. connected to the following link: http://wiki.fhb.fh-swf.de/wiki/index.php/_fhbwiki:<accesscontrol-redirect-users> I found out that I could solve this problem by editing the accesscontrol-tagline from: <accesscontrol>fl,,alle(ro)</accesscontrol> to <AccessControl>fl,,alle(ro)</AccessControl> but since I have no way to search for the accesscontrol-tag inside the wiki-pages I see no easy way to change over the old existing tags. Is there another way to solve this "bug"? Kate Katwol (talk) 06:51, 10 April 2017 (UTC)