Extension talk:Semantic ACL

Deprecated code has been patched.

i.e phab:T347127, phab:T304760.

It seems like we've ended up in a situation in which a Phabricator project was created despite Phabricator not serving as the canonical issue tracker, which seems unideal and almost led me to mark this as unmaintained when I found it in Category:ParserFetchTemplate extensions

I'm the maintainer and there are no other issue trackers. I'll get to it (as there are other upgrades I want to make).

Can I tag you on gerrit for code review ?

I don't have the right to merge patches anywhere, but sure I'm willing to look at some.

(I'm not actually running this extension anywhere, just trying to make MediaWiki.org look more up to date by cleaning Category:Extensions using removed hooks)

Thanks for doing that underlooked but nonetheless very important task ;)

I'll let you know when patches are up for review.

The patches for phab:T347127 and phab:T304760 have been applied.

Left some feedback on the patch. Thanks.

Hello again! The extension works great for removing permissions on public wikis (making some pages private), but I can't get the opposite to work - making some pages public on a default private wiki (mw 1.39.1 but i can upgrade!).

I've made the wiki private in the standard way - $wgGroupPermissions['*']['read'] = false;

I've gone through and confirmed that the extension is correctly computing the permission and the expected hooks are called, but still no dice. From reading the PermissionManager.php source, it seems like negative permissions are handled differently - eg. if there is any single check that says permission is denied, then that overrides the rest of them saying permission should be granted.

I know that Lockdown also says that it can only be used to restrict, not grant permissions, but I just have to believe that there is some way to override the permissions checking process! Maybe we would want to put that behind a config variable to check "yes i want Semantic ACL to completely override the rest of the permissions checking process."

Barring that, it should also be possible to remove the GroupPermissions setting if there was a way of setting a default ACL setting - so Semantic ACL controls all permissions, but by default (when unspecified) pages are set to [[Visible to::user]] (or whatever one sets the default permission to be).

Let me know if this is possible! I am willing to PR as well :)

Browsing through PermissionManager.php, it seems there are enough hooks around to maybe do that. Howerver, I cannot say for sure without actually trying...

The other option would actually be to replace that class with one that is custom to this extension and overrides any method that gets in the way of managing permissions the way we want. That will however make the extension harder to maintain and more prone to breaking when they make updates to MW's core.

That being said, my MW installation defaults to public, so I would not have an easy way to test that code.

Would you be willing to provide a patch ? I will be willing to make sure it does not break existing functionnalities and validate your code.

Sorry i am yet again seeing this four months later - i'll try again on a patch since permissions have been modified in recent mediawiki versions :)

Let me know when you're ready for review.

Changes pushed after this comment were made resolved the problem :)

Hello! On 1.39.1 with SMW installed, and I can't import the extension! I get this whenever I have it imported in my LocalSettings:

any tips?

8a0b56731bb396857f5ce546] /Main_Page Error: Call to a member function getOutput() on null

Backtrace:

from /var/www/html/mediawiki/extensions/SemanticACL/SemanticACL.class.php(464)
#0 /var/www/html/mediawiki/extensions/SemanticACL/SemanticACL.class.php(321): MediaWiki\Extension\SemanticACL\SemanticACL::disableCaching()
#1 /var/www/html/mediawiki/extensions/SemanticACL/SemanticACL.class.php(164): MediaWiki\Extension\SemanticACL\SemanticACL::hasPermission()
#2 /var/www/html/mediawiki/includes/HookContainer/HookContainer.php(338): MediaWiki\Extension\SemanticACL\SemanticACL::onBadImage()
#3 /var/www/html/mediawiki/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook()
#4 /var/www/html/mediawiki/includes/HookContainer/HookRunner.php(914): MediaWiki\HookContainer\HookContainer->run()
#5 /var/www/html/mediawiki/includes/BadFileLookup.php(80): MediaWiki\HookContainer\HookRunner->onBadImage()
#6 /var/www/html/mediawiki/includes/parser/Parser.php(2699): MediaWiki\BadFileLookup->isBadFile()
#7 /var/www/html/mediawiki/includes/parser/Parser.php(2458): Parser->handleInternalLinks2()
#8 /var/www/html/mediawiki/includes/parser/Parser.php(1639): Parser->handleInternalLinks()
#9 /var/www/html/mediawiki/includes/parser/Parser.php(724): Parser->internalParse()
#10 /var/www/html/mediawiki/includes/content/WikitextContentHandler.php(301): Parser->parse()
#11 /var/www/html/mediawiki/includes/content/ContentHandler.php(1721): WikitextContentHandler->fillParserOutput()
#12 /var/www/html/mediawiki/includes/content/Renderer/ContentRenderer.php(47): ContentHandler->getParserOutput()
#13 /var/www/html/mediawiki/includes/Revision/RenderedRevision.php(266): MediaWiki\Content\Renderer\ContentRenderer->getParserOutput()
#14 /var/www/html/mediawiki/includes/Revision/RenderedRevision.php(237): MediaWiki\Revision\RenderedRevision->getSlotParserOutputUncached()
#15 /var/www/html/mediawiki/includes/Revision/RevisionRenderer.php(221): MediaWiki\Revision\RenderedRevision->getSlotParserOutput()
#16 /var/www/html/mediawiki/includes/Revision/RevisionRenderer.php(158): MediaWiki\Revision\RevisionRenderer->combineSlotOutput()
#17 [internal function]: MediaWiki\Revision\RevisionRenderer->MediaWiki\Revision\{closure}()
#18 /var/www/html/mediawiki/includes/Revision/RenderedRevision.php(199): call_user_func()
#19 /var/www/html/mediawiki/includes/poolcounter/PoolWorkArticleView.php(91): MediaWiki\Revision\RenderedRevision->getRevisionParserOutput()
#20 /var/www/html/mediawiki/includes/poolcounter/PoolWorkArticleViewCurrent.php(97): PoolWorkArticleView->renderRevision()
#21 /var/www/html/mediawiki/includes/poolcounter/PoolCounterWork.php(162): PoolWorkArticleViewCurrent->doWork()
#22 /var/www/html/mediawiki/includes/page/ParserOutputAccess.php(299): PoolCounterWork->execute()
#23 /var/www/html/mediawiki/includes/page/Article.php(714): MediaWiki\Page\ParserOutputAccess->getParserOutput()
#24 /var/www/html/mediawiki/includes/page/Article.php(528): Article->generateContentOutput()
#25 /var/www/html/mediawiki/includes/actions/ViewAction.php(78): Article->view()
#26 /var/www/html/mediawiki/includes/MediaWiki.php(542): ViewAction->show()
#27 /var/www/html/mediawiki/includes/MediaWiki.php(322): MediaWiki->performAction()
#28 /var/www/html/mediawiki/includes/MediaWiki.php(904): MediaWiki->performRequest()
#29 /var/www/html/mediawiki/includes/MediaWiki.php(562): MediaWiki->main()
#30 /var/www/html/mediawiki/index.php(50): MediaWiki->run()
#31 /var/www/html/mediawiki/index.php(46): wfIndexMain()
#32 {main}

This fixes the error, but the extension is not working (on a private wiki, making a page visible to public :(

https://github.com/sneakers-the-rat/mediawiki-extensions-SemanticACL/commit/d8f526096babe846130c0e6c64dcab2bc3642754

The error was fixed on a commit dated march 24 but thanks for pointing it out.

Hello ! A user has provided a fix which I need to commit to the codebase. I'll let you know when this is done. Don't hesitate to send me a reminder in two weeks or so in case I forget.

The fix it seems is unrelated. Did you get the extension to work ? Is this a new install or an upgrade ?

Sorry I haven't checked in, Thanks for the quick response! I will try it again tomorrow :)

I'm working on upgrading my wiki to 1.40 and in the process I have fixed many a bug on the extension. The new code should be available in the next weeks.

Whoops, didn't realize i need to mark this as resolved - the problem of not being able to allow pages from a default private wiki remains - https://www.mediawiki.org/w/index.php?title=Topic:Xfa7amqvfghkrno0&topic_showPostId=xfa7amqvfkfmzrm8#flow-post-xfa7amqvfkfmzrm8

but the install issues are fixed. thanks!

Corrected.

Upgrading to MediaWiki 1361, and getting this error:

Use of $wgParser was deprecated in MediaWiki 1.32. [Called from MediaWiki\Extension\SemanticACL\SemanticACL::hasPermission in /var/www/mediawiki1362/extensions/SemanticACL/SemanticACL.class.php at line 303]

Per the mediawiki manual (Manual:$wgParser), it's a simple change.

I've replaced:

global $wgParser;

with:

$wgParser = new StubObject( 'wgParser', $wgParserConf['class'], array( $wgParserConf ) );

However, I don't know where to send a pull request to.

-Mitch

Hello Mitch,

Thanks for pointing this out.

Per Manual:$wgParser, you should rather use \MediaWiki\MediaWikiServices::getInstance()->getParser().

Morevover the code for this extension si hosted in Wikimedia's gerrit. Any change you could push a commit for review there?

I'll tackle these after vacation. :-)

Set $wgEnablePrivateLinks = false when using MediaWiki 1.31

Hello,

Mediawiki:1.31

PHP: 7.2

Ubuntu 18.04

SemanticACL: 0.2b (7b98339)

First of all I want to say thank you for creating this extension. It is easy to install, easy to use and works well 10/10 points on that.

My question is about the output that is shown to users that are not allowed to read a page.

On my wiki when accessing those pages a Internal error is returned:

[ce31e7dd85c22f9f4b3a1d91] /pmbd/index.php/Requirements_directory Error from line 376 of /var/www/html/pmbd/extensions/SemanticACL/SemanticACL.class.php: Call to undefined method MediaWiki\MediaWikiServices::getParserFactory()

Backtrace:

#0 /var/www/html/pmbd/extensions/SemanticACL/SemanticACL.class.php(88): MediaWiki\Extension\SemanticACL\SemanticACL::hasPermission(Title, string, User, boolean)

#1 /var/www/html/pmbd/includes/Hooks.php(177): MediaWiki\Extension\SemanticACL\SemanticACL::onSMWStoreAfterQueryResultLookupComplete(SMW\SQLStore\SQLStore, SMW\Query\QueryResult)

#2 /var/www/html/pmbd/includes/Hooks.php(205): Hooks::callHook(string, array, array, NULL)

#3 /var/www/html/pmbd/extensions/SemanticMediaWiki/src/SQLStore/SQLStore.php(366): Hooks::run(string, array)

#4 /var/www/html/pmbd/extensions/SemanticMediaWiki/includes/query/SMW_QueryProcessor.php(338): SMW\SQLStore\SQLStore->getQueryResult(SMWQuery)

#5 /var/www/html/pmbd/extensions/SemanticMediaWiki/src/ParserFunctions/AskParserFunction.php(364): SMWQueryProcessor::getResultFromQuery(SMWQuery, array, integer, integer)

#6 /var/www/html/pmbd/extensions/SemanticMediaWiki/src/ParserFunctions/AskParserFunction.php(197): SMW\ParserFunctions\AskParserFunction->doFetchResultsFromFunctionParameters(array, array)

#7 /var/www/html/pmbd/extensions/SemanticMediaWiki/src/ParserFunctionFactory.php(402): SMW\ParserFunctions\AskParserFunction->parse(array)

#8 /var/www/html/pmbd/includes/parser/Parser.php(3426): SMW\ParserFunctionFactory->SMW\{closure}(Parser, string, string, string, string, string, string, string)

#9 /var/www/html/pmbd/includes/parser/Parser.php(3127): Parser->callParserFunction(PPFrame_DOM, string, array)

#10 /var/www/html/pmbd/includes/parser/Preprocessor_DOM.php(1277): Parser->braceSubstitution(array, PPFrame_DOM)

#11 /var/www/html/pmbd/includes/parser/Parser.php(2942): PPFrame_DOM->expand(DOMElement, integer)

#12 /var/www/html/pmbd/includes/parser/Parser.php(1293): Parser->replaceVariables(string)

#13 /var/www/html/pmbd/includes/parser/Parser.php(443): Parser->internalParse(string)

#14 /var/www/html/pmbd/includes/content/WikitextContent.php(323): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)

#15 /var/www/html/pmbd/includes/content/AbstractContent.php(516): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)

#16 /var/www/html/pmbd/includes/poolcounter/PoolWorkArticleView.php(144): AbstractContent->getParserOutput(Title, integer, ParserOptions)

#17 /var/www/html/pmbd/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork()

#18 /var/www/html/pmbd/includes/page/Article.php(604): PoolCounterWork->execute()

#19 /var/www/html/pmbd/includes/actions/ViewAction.php(68): Article->view()

#20 /var/www/html/pmbd/includes/MediaWiki.php(500): ViewAction->show()

#21 /var/www/html/pmbd/includes/MediaWiki.php(294): MediaWiki->performAction(Article, Title)

#22 /var/www/html/pmbd/includes/MediaWiki.php(861): MediaWiki->performRequest()

#23 /var/www/html/pmbd/includes/MediaWiki.php(524): MediaWiki->main()

#24 /var/www/html/pmbd/index.php(42): MediaWiki->run()

#25 {main}

Is this the default message or is there a way to output a more user-friendly message when a user without permission is trying to access a page? Or maybe the error is on my side?

Thank you and Best Regards

Thanks for the comments. It's supposed to show a clean message and not a dump like that. The problem is the MediaWiki\MediaWikiServices::getParserFactory() call which is only defined in MediaWiki 1.32, which makes this extension incompatible with 1.31.

Can you easily upgrade you MediaWiki installation?

Thank you for the quick reply, outstanding support compared to other extensions I had trouble with.

Unfortunately I can't easily upgrade my mediawiki due to multiple extensions that are not supported on newer versions. I guess there is no easy workaround for that issue, right?

Is there another way to solve this issue?

I've dug into it and the faulty line is used only for private links. If you do not need that feature, set $wgEnablePrivateLinks = false in you LocalSettings.php.

Then, just comment out line 376 in /var/www/html/pmbd/extensions/SemanticACL/SemanticACL.class.php

Tell me if that works.

Hello Tinss,

Thank you for taking the time to look into this.

So I tried your approach and when commenting out line 376 of the SemanticACL.class.php ( "$parser =  \MediaWiki\MediaWikiServices::getInstance()->getParserFactory()->create(); // Use a new parser to avoid interfering with the current parser.") it doesn't work. The wiki returns a white page.

What worked however, was just setting $wgEnablePrivateLinks = false in my LocalSettings.php.

Thanks again for the support.

You're welcome!

Is there a way to protect pages with Semantic ACL recursively?

I want to add the code for protection in the wiki/firstpage page and when a new page e.g. wiki/firstpage/newpage is created it is supposed to be protected too. How is this configurable?

Hello,

It's not possible at the moment, but it's a feature I've wanted to implement for some time. You can check back here in a couple of months to see if this has been done or if you are versed in PHP programming you can definitely contribute a feature to the extension.

Hello,

i have installed the Semantic Media Wiki and the SemanticACL extensions today. Sadly i didn't get it to work properly, which is probable my fault. What i have done so far:

1. Added following lines to the LocalSettings.php

1. wfLoadExtension( 'SemanticACL' );

require_once "$IP/extensions/SemanticACL/SemanticACL.php"; (i tried both lines)

enableSemantics( 'Wikiname' );

$smwgNamespacesWithSemanticLinks[NS_MAIN] = true; $smwgNamespacesWithSemanticLinks[NS_Test1] = true;

2. I created a page inside the main namespace which contains the following lines:

The User Acltest has normally no rights to edit a page in this namespace and my hope was to give him the rights on this page using your extension. But it doesn't work for me. I also gave him the SMW-Administrator and SMW-Kurator rights but nothing changed. I think it has to do with the whitelist because i can't understand for what this line is used. Is it a page inside the wiki or a special param? Does anybody have an idea what went wrong? Thx in advance.

Hello,

You say that the user Acltest has no rights to edit the page. What is the feature that prevents the user from editing? Is it another extension? A MediaWiki feature?

Please also provide the wikicode you used to whitelist that user for editing the page.

Sorry forget that code:

<div style="display:none">
[[Editable by ::whitelist]]
[[Editable by user::User:Acltest]]
</div>

The feature that prevent the user from editing should be this LocalSetting param: $wgGroupPermissions['user']['edit'] = false;

The code you provided is correct.

However, I'm pretty sure restrictions from MediaWiki will override those of SemanticACL. I don't really know how one would go about preventing edit access to all pages but one. MediaWiki's design is more toward's openness rather than restriction.

Maybe if you can define basic rights in Extension:Header Footer so they can apply to all pages? Be careful though, this will disable caching for all pages in your wiki.

Thx for your help, Tinss. I will have to take a look into that Extension.

Use a hidden div or #set.

<div style="display:none">[[Visible to::whitelist]]</div>
{{#set:Visible to group=moderator}}

Hello,

unfortunately the pages with restricted access shows "Test whitelist ehtest whitelist ehtest"

in source editor, I used [[visible to:: whitelist]] [[visible to group:: ehtest]] [[editable by::whitelist]] [[editable by group:: ehtest]]

used only small letters in group name because I read that big letters and spaces may cause trouble

any suggestion or correction to my "code"?

Your code is correct. The values are shown in case the ACL status of a page needs to be displayed. To hide it, wrap them in a hidden div:

<div style="display:none;">[[visible to:: whitelist]] [[visible to group:: ehtest]] [[editable by::whitelist]] [[editable by group:: ehtest]]</div>

Hope this helps.

thank you very much :-)

ideally, this hidden div woraround would be mentioned in the install explanation

Done! Juste remembered you also had the option of using #set

<div style="display:none">[[Visible to::whitelist]]</div>
{{#set:Visible to group=moderator}}

This is just a PSA for those wanting a way of providing a protected namespace for private content that is also able to automatically protect files uploaded from a page in that namespace. The goal on my site was to give management a place to upload sensitive management files that are not available to non-management users. Here's how I did it:

1. Create a custom namespace called "Management"
2. Create a custom rights group called "management"
3. Use "Extension:Lockdown" to protect the "Management" namespace for user in the "management" right group
4. Use "Extension:SimpleBatchUpload" in a page in the Management namespace to provide the methods of uploading files with a template of {{Upload|viewedonlyby=management}}
5. Modify Template:Upload to test (#ifeq) for property {{{viewonlyby|}}} in {{Uploads}},
   • if so, then add [[Visible to group::management]] to all files uploaded with that template where |viewonlyby=management.
6. Use Extension:Semantic_ACL to limit access to the file by group management per the presence of [[Visible to group::management]].

In summary: Custom Namespace + Lockdown + SimpleBatchUpload + SemanticACL produces the overall effect.

Within the security limitations noted by MW, this method provides a very nice way of allowing management to add content that is not visible to non-management users.. a very handy thing for an enterprise site!

The wikitext {{#batchupload:Upload|viewonlyby=management}} will create an upload button in a page that will automatically protect any files uploaded by it as long as Template:Upload contains

{{#ifeq:{{{viewonlyby|}}}|management
| [[Visible to group::management]]
|
}}

Thank you for sharing your tips!

Works for any namespaces that are configured for semantic data.

Is there something I can do to get this to work in another namespace?

If this extension still works it should probably work as soon as this other namespace was enabled for holding semantic data.

That was it

Thanks