Making registration for media wiki require admin approval? - mediawiki

A wiki I maintain has been hit pretty hard by spam bots... we don't have a lot of users, and I'd rather not saddle the legitimate users with captcha. Is there a simple way to make registration confirmation go to an admin? I've looked through the manual, and haven't been able to figure out how to do it.

You could create a new user right, e.g. "approved", allow admins to assign that right and restrict things like editing to only approved users, like this:
// Disallow editing and uploading from anons and registered users
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
// New user group: approved users
$wgGroupPermissions['approved']['edit'] = true;
// Allow admins to approve (and unapprove) users via Special:UserRights
$wgAddGroups['sysop']['approved'] = true;
$wgRemoveGroups['sysop']['approved'] = true;
Note that removing the edit permission also stops non-approved users from doing most things that directly or indirectly involve changing pages in any way, so you shouldn't need to revoke those rights explicitly.
Also, instead of revoking editing rights from unapproved users completely, you could restrict their editing to certain namespaces using $wgNamespaceProtection (and perhaps further to certain pages in those namespaces using normal per-page protection), something like this:
// Limit editing of the main namespace to approved users
$wgNamespaceProtection[NS_MAIN] = array( 'edit-main' );
$wgGroupPermissions['approved']['edit-main'] = true;
That way, you could set up a page where new users can ask to be approved in one of the namespaces they can edit.
For more information, see Manual:User rights and Help:Assigning permissions on mediawiki.org.

If you're willing to install an extension then Extension:ConfirmAccount would be the best solution for you.
"The ConfirmAccount extension disables direct account creation and requires the approval of new accounts by a bureaucrat"
This means that new users are clearly told within the interface, that they are requesting a user account. It also presents a specially designed interface to the administrators, for approving the requests, and will email somebody (configured email address $wgConfirmAccountContact) when somebody's waiting.
Although spammers can still irritate you a little by requesting accounts (use in conjunction with ConfirmEdit captcha is recommended), they will not be getting as far as actually creating junk user accounts.

Related

Retrieve the list of users in a Google Apps Domain with a non-admin account

Is it possible to retrieve the list of users in a Google Apps Domain with a non-admin account?
Non-admin users can call users.list(viewType=domain_public) which offers the same amount of details that the users see in the domain contacts directory.
Depends on what you think an admin account is.
Long ago the user roles were just "regular" and "admin". Now you can choose from a fine-grained set of permissions and define a role name for them. "Superadmin" is now a built-in role that has every permission possible.
So, if you define a role which can retrieve the user list and assign it to a user I wouldn't call it an admin account.
You need to be a true admin to do that, though :)
As a complement to the other (excellent) answer, what I do in our domain is to create a full list of domain users in a spreadsheet with all necessary informations and run a script every night that updates the spreadsheet automatically. When I make a change (add or remove user) I can run the script manually to avoid temporary differences.
This script runs as "me" but any domain user has access to the list (I invite them to this shared doc when I create their account so it shows up in their drive/shared with me folder). With this solution I don't need to give special rights to any users.

Restricting access to Site Public pages for select Users

Is it possible to restrict access of Site public pages for a few Users through configuration?
Now by default in liferay anybody can access the Public pages [that is the reason they are named Public Pages :-) ] of any Site whether Open, Restricted or Private.
In our system we force login to access even Public pages, but once logged-in the User can see the public-page of any Site if he has the URL for it.
To make the requirement more clear:
I have 3 users in the system, User01, User02, User03.
I have 3 Sites - Site01 (open), Site02 (restricted), Site03 (private)
These Sites have only one User respectively.
All these 3 users can see public-pages of all three Sites. So now what I want is that only User02 should be an exception, that is User02 should not be able to access the Public-pages of Site01 and Site03.
Is this possible through configuration? Or will it require changes in liferay code (possibly through hook)?
Even if we can limit access to Public-pages for all Users who are not member of that Site that will also work?
Any ideas or help is much appreciated. Thanks.
Here are few steps to achieve this:
You can remove view permission from guest role(or all role as per your requirement) to specified page(here from public pages as per your
requirement) from manage permission tab of page.
Create a new role(which will allow view permission) and from manage permission of page assign this role view permission.
Now assign these newly created role to users to whom you want to have view access to pages
For your last question
Even if we can limit access to Public-pages for all Users who are not
member of that Site that will also work?
This can be achieved by removing VIEW permission for Guest role for each of Public pages of site.
HTH,
Thanks,

Integrating multiple user account tables

I have three websites: a.example.com, b.example.com, and c.net. Each was built a couple years after the other and all have their own users table.
I want to integrate these sites together so that I can login with a single username/password combo and have access to all three sites just by clicking links without having to login again.
I've never done an integration like this before, so looking at two angles:
1) Create another website, 'd.net' where new accounts can be created. If you login to one of the original three sites, it asks you for your d.net account. If you dont have one it asks you to make one. In your 'account settings' on d.net, you can 'add sites' to your account by entering your old username and password for them. Sound reasonable?
2) Solving the technical problem of being able to one-click login to another of the three sites if i'm already logged into d.net. Afaik, cookies with a session ID can't be shared across domains. So... maybe generate a token and save it to the database. Send token over GET to another website, which can check the token, log the user in, and then delete the token. Sound about right?
Have you looked at OpenID?
http://en.wikipedia.org/wiki/OpenID
Don't have to re-invent the wheel.

how to require 'confirm by email' to create an account in mediawiki

I have a site built on mediawiki. How do I ensure that to create a new account the user must first confirm his email by clicking a link sent to his email address?
There is no built-in way to do that that I know of although you can get pretty close. The $wgEmailConfirmToEdit variable let's you prevent people from editing unless they have confirmed their email address. Just set:
$wgEmailConfirmToEdit = true;
in your LocalSettings.php

Delete or disable user in mediawiki

How can i disable or delete an user in mediawiki?
I can delete the records from the db but i am not sure if this would affect anything else in the wiki.
Any suggestions would be welcome
Thanks
Prady
1. This solutions is available out of the box for MediaWiki 1.16+
The user and all the contributed content will remain but they will not be able to log in any more.
There are two steps that need to be done:
First block the user using the link in Special Pages.
Blocking can be performed against user id or IP address to prevent them from editing the wiki.
They will still be able to log in and view content.
Then in LocalSettings.php add $wgBlockDisablesLogin=true; ($wgBlockDisablesLogin).
Now upon logging in the user will be greeted with Login error. This user is blocked. Login not allowed..
2. This solutions requires an extension that works with MediaWiki 1.29+
If you want to completely remove access to a user, e.g. on a simple private wiki, it's not possible to simply delete the account (unless no edits have been made); you can block it, but the user will still be able to read pages. However, using User Merge and Delete extension you can merge the account in another one and delete the former; the original account will then "disappear".
Also:
If you want to preserve history readability (i.e., to have edits from the user to be still shown under his name), you can create a new account e.g. with username "OriginalUserName (deactivated)" and then merge "OriginalUserName" into the former, or even use Renameuser extension.
I suppose if you wanted to revive the user later on you would need to repeat this process but this time you would merge OriginalUserName (deactivated) into OriginalUserName.
See Preventing Access page in the MediaWiki manual.
There's a special page that Admin users can see, /Special:BlockIP. Block them there.
You can also get to it from the Special Pages page, /Special:SpecialPages.
you could also reset the password of the user via
/Special:PasswordReset
note: I would not recommend deleting data via scripts in the DB. there are various functionalities for rolling back unwanted user edits, merging contribution from one user to another, etc.