Several years ago, I used mediawiki to create a wiki. I had(still have) no idea really how to administrate it. I wanted it to be maintained/updated by only myself. It was to hold a specific set of information for my users.
After a few weeks it became flooded with User submitted pages (in this case not a good thing) and I guess what you'd call "spammers"(?).
How can I set it up so that only a legitimate admin (me) can add/update page?
I thought I had enabled something to do that...but it apparently didn't work.
In MediaWiki, permissions (read, edit, createpage, etc.) can be granted or refused by configuring the $wgGroupPermissions array in your LocalSettings.php file.
There is a set default groups that you can use with $wgGroupPermissions to restrict page creation/editing:
* - all users (including anonymous)
user - registered accounts
autoconfirmed - registered accounts at least as old as $wgAutoConfirmAge and having at least as many edits as $wgAutoConfirmCount
bot - accounts with the bot right (intended for automated scripts)
sysop - users who by default can delete and restore pages, block and unblock users, et cetera
bureaucrat - users who by default can change other users' rights
The group that would apply to only you (as the creator of the wiki) is the sysop group.
For example, to refuse createpage/edit rights for all users except those with the sysop group, you would place this in your LocalSettings.php:
# Deny createpage and edit rights to all users
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['edit'] = false;
# Allow only users with the sysop group createpage and edit rights
$wgGroupPermissions['sysop']['createpage'] = true;
$wgGroupPermissions['sysop']['edit'] = true;
The "*" character indicates that this rule will apply to all groups. Then, we add an exception to that rule for the "sysop" group, allowing users with that group to create or edit pages.
Related
I'm trying to setup a MediaWiki for university students. Using the EmailDomainCheck, I prevent anyone except those with a university based email from creating accounts. Using $wgEmailConfirmToEdit, I can require that an email is confirmed before the user can edit files. However, as it is, a user can use a fake email from the correct domain to create an account. With the account they can view all pages (even though they cannot edit them). I do not want to grant them read access unless the email has been confirmed. Is this possible? Note, I want all confirmed emails of the correct domain to be automatically accepted. It should not require manual account creation acceptance.
You could try the following, as outlined in the Documentation
# Disable for everyone.
$wgGroupPermissions['*']['read'] = false;
# Disable for users, too: by default 'user' is allowed to read, even if '*' is not.
$wgGroupPermissions['user']['read'] = false;
# Make it so users with confirmed email addresses are in the group.
$wgAutopromote['emailconfirmed'] = APCOND_EMAILCONFIRMED;
# Hide group from user list.
$wgImplicitGroups[] = 'emailconfirmed';
# Finally, set it to true for the desired group.
$wgGroupPermissions['emailconfirmed']['read'] = true;
As Jenny Shoars has mentioned, you may wish to whitelist some pages such as:
$wgWhitelistRead = array("Main_Page", "Special:CreateAccount", "Special:ConfirmEmail");
So that non registered users can still create accounts and the like.
In theory,
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['emailconfirmed']['read'] = true;
should work. In practice, MediaWiki almost always used with an "everyone can read" or "you can read iff you are logged in" setup and others are not very well tested, so if that wiki had some highly sensitive private information I wouldn't do this, but I imagine for a university website that's not the case.
Alternatively, it should not be too hard to integrate an email confirmation step into account creation, but you'd have to write the code for that. EmailAuth (which does a similar check during login) might give you an idea of how that would look.
I'm using mediawiki 1.13.3 running on freebsd 7.4
I've got confused with the following task:
how to deny access to All pages for certain users (who has account in my wiki) or for group of these users but allow ReadOnly access for certain pages on wiki.
The goal to achieve is to have no access to pages on wiki except allowed few for some users.
I've tried some extensions but can't find a solution for ~20000 pages and few hundreds of users.
See Manual:Preventing access on mediawiki.org, section "Restrict viewing of all pages".
Specifically, to allow everyone to read (but not edit) the Main Page and a page named Public stuff, and to allow only sysops to read and edit all pages, you'd add the following lines to your LocalSettings.php:
# prevent editing and reading by anons (except for exception listed below):
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
# same for normal registered users:
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['read'] = false;
# allow everyone read access to these pages:
$wgWhitelistRead = array( "Main Page", "Public stuff" );
# allow sysops to read and edit normally:
$wgGroupPermissions['sysop']['edit'] = true;
$wgGroupPermissions['sysop']['read'] = true;
Of course, you can replace sysop above with your own custom user group; I just used it in the example because it exists in a stock MediaWiki install.
(Some older example code suggests also including "Special:UserLogin" and possibly "Special:ChangePassword" and "Special:PasswordReset" in $wgWhitelistRead. In modern MediaWiki versions this should be unnecessary, although still harmless.)
A quite close solution I've found is using simple security extension:
So I'm creating a user group with no access:
$wgGroupPermissions['user']['read'] = false;
add this group to $wgRestrictionLevels = array();
and then restricting read access for some pages to this group.
Fairly enough but not exactly the solution I want to achieve.
I'm currently working on a platform which is planned to coordinate the communication with customers in future. Users can be added to projects and have certain rights. Therefore users are assigned to different user roles (admin/manager/member/viewer). Admins can view all projects and are allowed to add other users to a project. If a user (e.g. role:member) is added to a project, he will have certain rights (depending on the role), if not, he is not allowed to access the project at all.
I'm using Cake's ACL Component and everything is working great, when i disregard if a user is added to a project or not. The only solution I can think of, is not to grant rights on the group-level, but on the user-level when an admin adds an user to the project.
Is there an easier way to solve this issue? Otherwise I'm afraid that the code would become totally confusing.
There is a another way (I don't really know if easier, depends on your point of view). The ACL component only helps you to create roles, but you need a role and project-access management, right?
What I do in this cases:
Create a Project_Permission table in your database (give it a better name, I'm lacking imagination). Depending on your project, create the associations: a user can be related to many projects and a project can have many users accesing it. If you are following the cake conventions (and your tables are named users and projects) and it doesn't interfere with what you already have, the table should be
PROJECTS_USERS
id
project_id
user_id
created and modified //if you want to
Create appropriate actions where the admin (or other type if users, that's up to you)
can add users to projects and save that many-to-many association in
the previously created table.
Since the authorization for the project does not come from the ACL component, you have to create an "authorization" function yourself. I recommend putting this in the beforeFilter() function of the AppController (if you don't have an AppController, you'll have to do it in every controller you want this to work). In this function, check if the logged user is in the existing table and has an association with the project. Something like:
function beforeFilter() {
//let's assume you have the project id somewhere, in a global variable like $this->_projectID
$user = $this->Session->read('Auth.User.id');
$project = $this->Project->find('first', array('conditions'=>array('id'=>$this->_projectID, 'User.id'=>$user)
if (count($project) > 0) {
//the user has permission to see the project
} else {
//he doesn't
}
}
It's difficult to give an actual code because I'm not sure of your model associations nor where do you want the code or if you have the variables needed for this available everywhere, but I hope you get the idea. After that it's just a matter of how you want to handle the restriction of access (normally a flash message and redirection is involved).
I hope this is clear enough :S
There are few pages on our wiki that I'd like to be able to protect from editing by people other than the assigned owner of that page.
We're currently running MediaWiki v1.15.4 and are unable to update to 1.18 for the time being.
Thanks in advance.
Edit: Just to clarify, the permissions need to be set for individual users and not by groups.
I had a similar problem where I needed more flexibility than the default system offered. I solved this by this script (embedded in a mediawiki extension):
// check each page for gossip permissions
$wgHooks['ArticlePageDataBefore'][] = 'GossipProtection_check_permissions';
/**
* ArticlePageDataBefore hook
*
* $article: article that is requested
* ($fields: not important)
*/
function GossipProtection_check_permissions($article, $fields) {
global $wgUser;
$title = $article->getTitle()->mTextform;
if(is_gossip_page($title))
if(!this_user_is_allowed_on_page($title))
die('You are not allowed on this page');
return true;
}
But using mediawiki's protection service is off course more elegant. You could for example create a group for the allowed users.
I'm checking if this is a sitecore bug, or if I'm missing something obvious.
EDIT FOR CLARIFICATION: The problem I'm having is that I'm trying to set up the configuration settings in the Domains.config file so that Sitecore shouldn't be creating (and/or returning) an anonymous user for a domain set up this way. However, if I use the Domain.GetUsers() function on the domain, I still get the anonymous user returned.
The membership provider is a custom built and connects to LDAP in read only mode.
Details
Using Sitecore 6.4.1 and given the following domain configuration in App_Config/Security/domains.config
<domain name="DOMAINNAME" ensureAnonymousUser="false" anonymousUserName="" everyoneRoleName="" />
and these comments in that domain.config file
anonymousUserName: <snip> Set to blank to disable the anonymous user for the domain. Optional
ensureAnonymousUser: Indicates if the domain should ensure that an anonymous user for the domain exists in the Membership database. Optional - default value: false
everyoneRoleName: <snip> Set to blank to disable the everyone role for the domain. Optional - default value: Everyone
If I use the following code,
List<Sitecore.Security.Accounts.User> users = new List<Sitecore.Security.Accounts.User>();
var domain = Sitecore.Security.Domains.Domain.GetDomain(DOMAINNAME);
users.AddRange(domain.GetUsers().ToArray<Sitecore.Security.Accounts.User>());
I get the anonymous user included in users list. I assumed from the comments in the domain.config file that I shouldn't get the anonymous user if I set up my domain as above.
Is there something obvious that I'm missing?
Just a guess as I have not used 6.4 yet or tweaked any of those types of setting before... but I believe Sitecore always comes pre-packaged with the Anonymous user in the membership. By setting ensureAnonymousUser to false you're just telling it not to ensure its there, but its already there by default. Why don't you try this test:
Set ensureAnonymousUser to true then delete [*] the Anonymous user from the user manager.
Log out and back in and see if it's there again. If so then the "ensure" aspect of that worked. So...
Set ensureAnonymousUser to false then do the same thing. Does the user come back?
This is really just a hunch on how it works -- I don't have an environment like that setup right now to play with, but its worth a shot.
[*] - to delete a user form the User Manager, go to Sitecore > Security > User Manager
I think it's more question to membership provider you use. Take a look at Active Directory Module
Maybe this is something that could help you.