 Archives | |||
|---|---|---|---|
|
I've installed Lockdown to restrict the special namespace to sysop and cm user groups, but when testing it, it doesn't seem to work.
My LocalSettings.php contains the following:
wfLoadExtension( 'Lockdown' );
$wgNamespacePermissionLockdown[NS_SPECIAL]['*'] = [ 'sysop', 'cm' ];
Any advise? Thanks
Hi, I just updated to MediaWiki 1.37 and get now the following error:
Use of User::getEffectiveGroups was deprecated in MediaWiki 1.35. [Called from MediaWiki\Extensions\Lockdown\Hooks::onGetUserPermissionsErrors in /var/www/html/extensions/Lockdown/src/Hooks.php at line 123] in /var/www/html/includes/debug/MWDebug.php on line 375
I think the code should be fixed here. I hope someone could help out.
Found that in the release Notes of MW 1.35:
The following methods of the User class are deprecated: getGroups, getGroupMemberships, getEffectiveGroups, getAutomaticGroups, addGroup, removeGroup, getFormerGroups, getAllGroups, getImplicitGroups, addAutopromoteOnceGroups. Use the new UserGroupManager service instead.
So I would say, the Extension is not supported for MW 1.37. Hopefully someone will fix that. I am using the extension for so long without any trouble.
Have you upgraded your extension to the newest version? I viewed the commit history and saw one commit fixing it.
I encountered the same problem when using Lockdown from the REL1_37 branch. The commit fixing this issue is only in the master branch right now. Ideally the fix would be merged into REL1_37 so users of Mediawiki 1.37 won't have to choose the master (development) branch.
Hi, i tried to create a new custom namespace, and a group that can edit this namespace and only this namespace, but can read all the other namespaces using the Lockdown extension. Here is the settings i made.
I'm using MW 1.35.
The new namespace is DATALAN, the new group is datalan.
define("CUST", 3001);
define("USR", 3002);
define("DATALAN", 3003);
$wgExtraNamespaces[CUST] = "Customization";
$wgExtraNamespaces[USR] = "Users_guide";
$wgExtraNamespaces[DATALAN] = "Users_guide_SVK";
$wgGroupPermissions['datalan']['read'] = true;
$wgGroupPermissions['datalan']['edit'] = true;
$wgGroupPermissions['datalan']['createpage'] = true;
$wgGroupPermissions['datalan']['delete'] = true;
$wgGroupPermissions['datalan']['move'] = false;
$wgAdminCanReadAll = true;
$wgAccessControlRedirect = false;
$wgNamespacePermissionLockdown['*']['edit'] = [ 'bureaucrat'];
$wgNamespacePermissionLockdown[CUST]['read'] = array( 'bureaucrat','reader');
$wgNamespacePermissionLockdown[USR]['read'] = array( 'bureaucrat','reader');
$wgNamespacePermissionLockdown[DATALAN]['read'] = array( 'bureaucrat','reader', 'datalan' );
$wgNamespacePermissionLockdown[DATALAN]['edit'] = array( 'datalan');
If i enable the Lockdown extension, the edit icon on the pages inside the DATALAN NS are disappearing for the users in the group datalan. The reading restrict acces works perfectly, if a user in a datalan group tries to read a page, that is in CUST namespace or the other.
I woulde be very happy if somene can help me!
Thanks!
hello i'm from indonesia sorry if i'm wrong in english.. #ask i want to create a hidden page on mediawiki so that only me can see/edit the page i tried to use extension lockdown but the problem is i can't configure it. can anyone help with my problem
As a newbie, there seems to be such a basic conflict on the main page of this extension, I wonder if I'm missing something -
$wgSpecialPageLockdown['Export'] = [ 'user' ];
Is described in the Example to 'PREVENT access to Special:Export to logged in users (registered user)'
But in the Configuration it is described as 'to limit the use of Special:Export to logged in users'
'user' means everyone with an active account.
anonymous persons can't export with this setting.
maybe you want disallow for all or restrict to 'sysop'
In order to restrict access to the Page Information (for ex. https://mediawiki.my.domain/index.php?title=Main_Page&action=info) for the anonymous users, I tried this:
wfLoadExtension( 'Lockdown' );
$wgSpecialPageLockdown['PageInfo'] = [ 'sysop' ];
$wgSpecialPageLockdown['Info'] = [ 'sysop' ];
but it doesn't work, the page won't be restricted. Does anybody know a solution for this?
These aren't special-Pages, that are actions.
so
$wgActionLockdown['info'] = [ 'user' ];
will restrict the page to user with account
You can protect them using administrator rights to "Allow only autoconfirmed users" - this will only prevent editing but not viewing
I have a wiki running 1.23wmf11 and the latest build of VisualEditor, the WYSIWYG editor from Wikimedia. It uses a node.js-based parser to round-trip wikitext called Parsoid.
I have defined a few custom name spaces and enabled VisualEdtior for those name spaces. Everything is working as intended.
If I use $wgNamespacePermissionLockdown to define read and edit rights for user groups VisualEditor does not work.
Instead I'm prompted with a "Error loading data from server: parsoidserver-http-bad-status: 500."
Editing the page with WikiEditor works as intended.
node spits out the following when the attempt to edit is made.
starting parsing of localhost:DBC:Cache_Shadowing_Stop/Start_Suspend/Resume ERROR in localhost:DBC:Cache_Shadowing_Stop/Start_Suspend/Resume with oldid: 123915 Stack trace: Error: API response is missing query for: DBC:Cache_Shadowing_Stop/Start_Suspend/Resume at TemplateRequest._handleJSON (/var/www/Parsoid/lib/mediawiki.ApiRequest.js:270:11) at TemplateRequest.ApiRequest._handleBody (/var/www/Parsoid/lib/mediawiki.ApiRequest.js:192:7) at TemplateRequest.ApiRequest._requestCB (/var/www/Parsoid/lib/mediawiki.ApiRequest.js:149:8) at Request.self.callback (/var/www/Parsoid/node_modules/request/request.js:129:22) at Request.EventEmitter.emit (events.js:98:17) at Request.<anonymous> (/var/www/Parsoid/node_modules/request/request.js:873:14) at Request.EventEmitter.emit (events.js:117:20) at IncomingMessage.<anonymous> (/var/www/Parsoid/node_modules/request/request.js:824:12) at IncomingMessage.EventEmitter.emit (events.js:117:20) at _stream_readable.js:920:16
It sounds like the Lockdown extension is somehow getting in the way of Parsoid and the MediaWiki api to make it's calls.
While VisualEditor is not the default editor for MediaWiki, its active development and future roadmap seem to indicate that it will be a preferred way to edit wiki pages for many editors. Any inputs and thoughts would be appreciated.
Hi, did you ever find a solution for this?
I'm running the Lockdown extension on MediaWiki 1.24.1 with the latest build of VisualEditor and I'm running into the same behavior where I'm unable to edit protected namespaces using VisualEditor.
Any help would be greatly appreciated!
I am having the same issue. Pages that are under a namespace which is locked by Lockdown can't be edited with VisualEditor. WikiEditor works just fine.
https://www.mediawiki.org/wiki/Extension:VisualEditor#Linking_with_Parsoid_in_private_wikis
Enabled cookies, still can't get VisualEditor to work on protected pages with Lockdown.
I created a new group called testgroup with a tool AccessControlPanel (frontend to Lockdown) and visited the page testgroup:Main_page in a browser where I was logged in (Firefox) and in another browser (Chrome). In first browser, I saw the edit button to edit the page in VisualEditor and then I got error (js alert dialog) "novenamespace: VisualEditor is not enabled in namespace 138" and after a reload, the VisualEditor Tab button disappeared.
In Chrome the page was restricted and I needed to log in to be able to see it, as expected.
If I manually create a namespace and if I restrict the namespace (read) to a user group in LocalSettings.php, every page created in that namespace can't be edited with VisualEditor. Only with WikiEditor.
Editing any other page that isn't restriced with Lockdown can be edited with VisualEditor.
BUMP
I have this identical issue using MW 1.25, parsoid 0.3.0 and the latest drops of Visual Editor and Lockdown.
Did anyone reach a solution for this?
Hello everyone.
We just have the SAME issue with Visual Editor and Lockdown.
Did anyone find a solution ??
Is this an inevitable problem with lockdown ?
We've been looking for a solution since all the day and nothing's working.
We've trying every solutions posted on the internet and .. no.
Please is there a god on this earth able to help us ??
Thank you
Hi everybody,
I think the problem is solved in newer Versions of MW and VE, as in my Installation of
MediaWiki 1.27.0-wmf.11 and
VisualEditor 0.1.0 (a6e24f4) 00:37, 1 February 2016
with VisualEditor enabled for the "Project" Namespace, which is write protected by Extension:Lockdown I am able to successfully edit those protected pages with VE. I have a Parsoid-server running on an a private backend-network and I am doing cookie-forwarding.
The Parsoid-server is a git clone from the beginning of February 2016.
Greetings
Hermann
Hi,
Encouraged by Hermann's example, I tried with latest night (2016.02.24) builts of every bit of software involved but I still get this message :
Erreur lors du chargement des données du serveur : 500: parsoidserver-http: HTTP 500. Voulez-vous réessayer ?
Thanks for any help.
Hi @Dieudo,
this looks like a configuration-error or something. Your parsoid-server had some kind of problem and answered with HTTP code 500 ("Internal Server Error").
How do you start parsoid?
And what do you see it output when you run it with
parsoidConfig.debug = true;
in you localsettings.js?
Greetings
Hermann
Actually it looks like there's a problem with my lockdown configuration alone. I'll have to check that first. Thx for your help Hermann : )
The error I get now is :
Fatal error: Call to a member function getId() on a non-object in .../extensions/Lockdown/Lockdown.php on line 163
Sorry, I forgot to mention that. There seems to be a bug in Lockdown in combination with MW 1.27 - see https://phabricator.wikimedia.org/T127456
Just add this code before line 162:
if ( !$wgUser ) {
return true;
}
Thank you Hermann !
This does the trick : )
However, it does it only if when including this line in LocalSettings.php :
$wgGroupPermissions['*']['read'] = false;
I wonder what to do to be able to use both Lockdown and VisualEditor on a wiki not private.
Any idea ?
My solution was, not to load Lockdown, if the request comes from the localhost. In an other configuration I had to take the non-local IP-adress of the server
if ( $_SERVER['REMOTE_ADDR'] != '127.0.0.1' ) {
require_once( "extensions/Lockdown/Lockdown.php" );
}
Additionaly the namespaces had to be activated for VE with $wgVisualEditorAvailableNamespaces
$wgVisualEditorAvailableNamespaces = array( NS_MAIN => true, NS_USER => true, NS_HELP => true, NS_PROJECT => true, NS_MYCUSTOMNAMESPACE => true, );
And read and edit permissions had to be given globally if request came from localhost
if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' ) {
$wgGroupPermissions['*']['read'] = true;
$wgGroupPermissions['*']['edit'] = true;
}Hi i have the same Problem here.
Where do you put the if Arguments? In the LocalSettings.php?
Hi guys,
I'm dealing with the same issue. If Lockdown is enabled, then VE refuses to save *any* page dispalying message "Permission denied". If I disable Lockdown by commenting out this section:
if ( $_SERVER['REMOTE_ADDR'] != '127.0.0.1' AND $_SERVER['REMOTE_ADDR'] != '::1' ) {
require_once "extensions/Lockdown/Lockdown.php";
}
Then VE works as hell.
I'm using the latest stable mediawiki, parsoid, Lockdown and VE.
My LocalSettings includes also:
$wgVisualEditorAvailableNamespaces = array(
NS_MAIN => true,
NS_USER => true,
NS_HELP => true,
NS_PROJECT => true,
NS_RESTRICTED => true
);
if ( $_SERVER['REMOTE_ADDR'] == '127.0.0.1' OR $_SERVER['REMOTE_ADDR'] == '::1' ) {
$wgGroupPermissions['*']['read'] = true;
$wgGroupPermissions['*']['edit'] = true;
} else {
# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
}
Do you have any idea how this issue can be fixed?
Thanks in advance.
Maciej
Mediawiki: v1.32.1
NodeJS: v10.15.3
Distribution: Debian GNU/Linux 9.8 (stretch)
Parsoid + VisualEditor + Lockdown (with SSL):
1) sudo apt install xs-utils
2) sudo wget https://nodejs.org/dist/v10.15.3/node-v10.15.3-linux-x64.tar.xz -O /usr/local/src/nodejs-10.15.3.tar.xz
3) sudo tar xf /usr/local/src/nodejs-10.15.3.tar.xz -C /usr/local/ --stript-components 1
4) sudo npm install -g parsoid
5) sudo vim /usr/local/lib/node_modules/parsoid/config.yaml
services:
- module: lib/index.js
entrypoint: apiServiceWorker
conf:
mwApis:
- uri: 'http://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php'
# - uri: 'https://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php' # If you redirect all HTTP traffic to HTTPS
# - uri: 'http://{{ other_fqdn }}/{{ mw_wiki_dir_name }}/api.php'
------ END config.yaml -------
6) sudo vim /etc/systemd/system/parsoid.service
----- START parsoid.service -----
[Unit]
Description=Mediawiki Parsoid web service on node.js
Documentation=http://www.mediawiki.org/wiki/Parsoid
Wants=local-fs.target network.target
After=local-fs.target network.target
[Install]
WantedBy=multi-user.target
[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/usr/local/lib/node_modules/parsoid
ExecStart=/usr/local/bin/node /usr/local/lib/node_modules/parsoid/bin/server.js
KillMode=process
Restart=on-success
PrivateTmp=true
StandardOutput=syslog
----- END parsoid.service -----
7) sudo service parsoid start (this load parsoid on port 8000)
8) sudo systemctl enable parsoid
9) sudo apt install stunnel
10) sudo vim /etc/stunnel/parsoid.conf
----- START parsoid.conf -----
cert = /etc/ssl/certs/{{ fqdn }}.crt
key = /etc/ssl/private/{{ fqdn }}.key
CAfile = /etc/ssl/certs/ca-certificates.crt
[parsoid]
accept = 8143
connect = 8000
----- END parsoid.conf -----
11) sudo vim /etc/default/stunnel4
----- START stunnel4 -----
...
# Change to one to enable stunnel automatic startup
ENABLED=1
...
----- END stunnel4 -----
12) sudo service stunnel4 restart (now you can reach parsoid on 8143)
13) sudo vim .../w/LocalSettings.php
----- START LocalSettings.php -----
...
// NEW Namespaces
define("NS_NEW_1", 3000);
define("NS_NEW_1_TALK", 3001);
$wgExtraNamespaces[NS_NEW_1] = "NEW1";
$wgExtraNamespaces[NS_NEW_1_TALK] = "NEW1_talk"; # Note underscores in the namespace name.
$wgNamespaceProtection[NS_NEW_1] = array( 'edit-new1' ); # "edit-new1" required to edit NEW1:pages
$wgNamespaceProtection[NS_NEW_1_TALK] = array( 'edit-new1-talk' ); # "edit-new1-talk" required to edit NEW1_talk:pages
$wgNamespacesWithSubpages[NS_NEW_1] = true; # subpages enabled for the NEW1 namespace
$wgGroupPermissions['new1']['edit-new1'] = true; # permission "edit-new1" granted to users in the "new1" group
$wgGroupPermissions['new1']['edit-new1-talk'] = true; # permission "edit-new1-talk" granted to users in the "new1" group
$wgContentNamespaces[] = NS_NEW_1; #prevent inclusion of pages from that namespace
$wgNonincludableNamespaces[] = NS_NEW_1;
$wgNonincludableNamespaces[] = NS_NEW_1_TALK;
wfLoadExtension( 'Lockdown' );
#restrict all permissions on pages with namespace "NEW" to users belonging to 'new1' group
$wgNamespacePermissionLockdown[NS_NEW_1]['*'] = array('new1');
$wgNamespacePermissionLockdown[NS_NEW_1_TALK]['*'] = array('new1');
wfLoadExtension( 'VisualEditor' );
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
// Don't allow users to disable it
$wgHiddenPrefs[] = 'visualeditor-enable';
$wgVirtualRestConfig['modules']['parsoid'] = array(
// URL to the Parsoid instance
// Use port 8142 if you use the Debian package
'url' => 'https://{{ fqdn }}:8143',
'forwardCookies' => true,
);
$wgVisualEditorAvailableNamespaces = [
NS_MAIN => true,
NS_USER => true,
NS_HELP => true,
NS_NEW_1 => true,
];
...
----- END LocalSettings.php -----
Parsoid + VisualEditor (without SSL):
1) sudo apt install xs-utils
2) sudo wget https://nodejs.org/dist/v10.15.3/node-v10.15.3-linux-x64.tar.xz -O /usr/local/src/nodejs-10.15.3.tar.xz
3) sudo tar xf /usr/local/src/nodejs-10.15.3.tar.xz -C /usr/local/ --stript-components 1
4) sudo npm install -g parsoid
5) sudo vim /usr/local/lib/node_modules/parsoid/config.yaml
services:
- module: lib/index.js
entrypoint: apiServiceWorker
conf:
mwApis:
- uri: 'http://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php'
# - uri: 'https://{{ fqdn }}/{{ mw_wiki_dir_name }}/api.php' # If you redirect all HTTP traffic to HTTPS
# - uri: 'http://{{ other_fqdn }}/{{ mw_wiki_dir_name }}/api.php'
------ END config.yaml -------
6) sudo vim /etc/systemd/system/parsoid.service
----- START parsoid.service -----
[Unit]
Description=Mediawiki Parsoid web service on node.js
Documentation=http://www.mediawiki.org/wiki/Parsoid
Wants=local-fs.target network.target
After=local-fs.target network.target
[Install]
WantedBy=multi-user.target
[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/usr/local/lib/node_modules/parsoid
ExecStart=/usr/local/bin/node /usr/local/lib/node_modules/parsoid/bin/server.js
KillMode=process
Restart=on-success
PrivateTmp=true
StandardOutput=syslog
----- END parsoid.service -----
7) sudo service parsoid start (this load parsoid on port 8000)
8) sudo systemctl enable parsoid
9) sudo apt install stunnel
10) sudo vim .../w/LocalSettings.php
----- START LocalSettings.php -----
...
// NEW Namespaces
define("NS_NEW_1", 3000);
define("NS_NEW_1_TALK", 3001);
$wgExtraNamespaces[NS_NEW_1] = "NEW1";
$wgExtraNamespaces[NS_NEW_1_TALK] = "NEW1_talk"; # Note underscores in the namespace name.
$wgNamespaceProtection[NS_NEW_1] = array( 'edit-new1' ); # "edit-new1" required to edit NEW1:pages
$wgNamespaceProtection[NS_NEW_1_TALK] = array( 'edit-new1-talk' ); # "edit-new1-talk" required to edit NEW1_talk:pages
$wgNamespacesWithSubpages[NS_NEW_1] = true; # subpages enabled for the NEW1 namespace
$wgGroupPermissions['new1']['edit-new1'] = true; # permission "edit-new1" granted to users in the "new1" group
$wgGroupPermissions['new1']['edit-new1-talk'] = true; # permission "edit-new1-talk" granted to users in the "new1" group
$wgContentNamespaces[] = NS_NEW_1; #prevent inclusion of pages from that namespace
$wgNonincludableNamespaces[] = NS_NEW_1;
$wgNonincludableNamespaces[] = NS_NEW_1_TALK;
wfLoadExtension( 'Lockdown' );
#restrict all permissions on pages with namespace "NEW" to users belonging to 'new1' group
$wgNamespacePermissionLockdown[NS_NEW_1]['*'] = array('new1');
$wgNamespacePermissionLockdown[NS_NEW_1_TALK]['*'] = array('new1');
wfLoadExtension( 'VisualEditor' );
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
// Don't allow users to disable it
$wgHiddenPrefs[] = 'visualeditor-enable';
$wgVirtualRestConfig['modules']['parsoid'] = array(
// URL to the Parsoid instance
// Use port 8142 if you use the Debian package
'url' => 'http://127.0.0.1:8000',
'forwardCookies' => true,
);
$wgVisualEditorAvailableNamespaces = [
NS_MAIN => true,
NS_USER => true,
NS_HELP => true,
NS_NEW_1 => true,
];
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:
{{Upload|viewedonlyby=management}}{{{viewonlyby|}}} in {{Uploads}},
[[Visible to group::management]] to all files uploaded with that template where |viewonlyby=management.[[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]]
|
}}
Hello, what's the right way to restrict the right to create a page in the Project-namespace (NS_PROJECT) to a certain group, but allow all other to edit them.
I tried this:
$wgGroupPermissions['*']['edit'] = true;
$wgNamespacePermissionLockdown[NS_PROJECT]['createpage'] = array('sysop');
But it wont work. Still every logged in user can create pages in the project namespace.
Hmm... , I do not think this can be done since action "edit" includes action "createpage" (some sort of "rights inheritance"). However, I may still be proven wrong.
I found a way using the Extension AbuseFilter with the following Filter and the "disallow" action:
(page_namespace = 0) &
(old_wikitext == "") &
!( 'sysop' in user_rights ) & !contains_any(added_lines, "redirect")
It is certainly not perfect and notifies the user only after hitting "save", but it works.
I am trying to do something similar and indeed it does not seem to work. I want only members of a certain group to be able to create pages on the main namespace, but allow everyone else to edit those pages once they exist.
Here is what I tried:
$wgGroupPermissions['user']['createpage'] = true;
$wgGroupPermissions['creator']['createpage'] = true;
$wgNamespacePermissionLockdown['*']['createpage'] = array('user');
$wgNamespacePermissionLockdown[NS_MAIN]['createpage'] = array('creator');
But it does not work. All users can still create pages on the Main Namespace, even if they are not members of the 'creator' group.
Too bad....