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.
Related
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.
in my html form there are two fields for password, one password and other confirm password. If the first password field does not match the second password field than do not submit the form to the database.
This is kind of a long shot since I don't know what your code looks like but this is a javascript example of disabling the submit button until passwords match.
var pass1 = document.getElementById('p1');
var pass2 = document.getElementById('p2');
if(pass1.value == pass2.value)
{
document.getElementById("enableButton").disabled = false;
}
else {
document.getElementById("enableButton").disabled = true;
}
Without knowing anything about your code - you should (could) do two things:
Verify that both passwords are the same via JavaScript on client side. That will bring up a better user-experience as you are able to display an error message / disable the form submission when the passwords are not the same. But please consider - many users still have disabled javascript by default, so that can not be the only validation.
Verify that the passwords are the same in PHP / Server-side code. How exactly you would achieve that depends on your scripting languages / architecture.
There are some in-depth discussions out there regarding password / authentication best-practices: this discussion or this cheat-sheet at owasp or this one in the php faq. Please take the security fundamentals mentioned there into account, too.
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.
How can I set it so that MediaWiki will not allow a single email address to create multiple accounts? A spambot just created 5 accounts with a single email.
I've looked for configuration settings or extensions, but haven't been able to find one.
A related issue to this is the annoying creation of spam accounts with usernames similar to JameeiohpbrxvlsHeadlon.
Spam prevention measurements work quite well, as no actual spam articles are created, but only spam accounts. I have TorBlock, ConfirmEdit and SimpleAntiSpam installed to prevent spam accounts from being created, but this appears to fail.
This is not likely to be a very effective anti-spam strategy. Most spambots smart enough to register accounts with valid e-mail addresses are likely also smart enough to try a new address if the registration fails.
Personally, I've found the most effective anti-spam solution for small wikis to be ConfirmEdit with QuestyCaptcha. Just configure ConfirmEdit to require a CAPTCHA for account creation, so that you won't get spam accounts. The questions don't need to be hard to answer — indeed, they can be absolutely trivial, as long as they're unique to your site.
That said, you could do what you suggest by writing an AbortNewAccount hook to look up the user's e-mail address in the database and fail if you find a match, something like this (untested!):
$wgHooks['AbortNewAccount'][] = 'disallowDuplicateEmails';
function disallowDuplicateEmails( $user, &$message ) {
$email = $user->getEmail();
if ( !$email ) return true; // allow empty e-mail
$dbr = wfGetDB( DB_SLAVE );
$name = $dbr->selectField( 'user', 'user_name',
array( 'user_email' => $email ),
__METHOD__ );
if ( $name !== false) {
$message = wfMessage( 'signup-dup-email', $email, $name )->text();
return false;
}
return true; // no match
}
You'll also need to create the system message page MediaWiki:signup-dup-email, with content something like this:
The e-mail address <tt>$1</tt> is already used by [[User:$2|$2]].
Note that there are at least two potential issues with such a check:
It can allow people to "fish" for e-mail addresses of your users (something that MediaWiki normally treats as private information) by trying to register a new account with an address they suspect might belong to an existing user. This could be somewhat mitigated by omitting the username from the error message, but that would still leak the information that someone is using the address.
The code above doesn't check whether the address has been confirmed or not (and checking that would rather defeat its purpose, unless you also require all users to confirm their e-mail address), and so a malicious person could prevent someone else from registering with their e-mail address by creating a dummy account with the same address.
However, getting around the check would actually be rather easy, since a) it checks for an exact match, so e.g. just changing the capitalization of the host name would be enough to make the check pass, and b) it doesn't prevent users from changing their e-mail address to whatever they want after registering, anyway. Both of these holes could be blocked, but it would require more effort.
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.