Limit user registration to specific domain or manually approve registrations

Is there a way to limit registrations of new users to only a specific domain name. For example I want to have a public site for viewing, but only want contributors to the wiki to be people of a specific domain (specific company or association). Is there a way to limit only a specific domain name from registering?

Is that a quick code someone could write patch for if needed?

If not, does Foswiki have built in functionality to allow admin to manually approve registrations?

Thanks!

You can configure your webserver to allow access to the registration pages only to the domain you want. I don't know about a registration approval mechanism... can somebody else help?

-- GilmarSantosJr - 08 Apr 2009

At my work, everybody can register but there are groups set up per web, so registering won't let people write until someone adds them to the permission group too. Works very well because we have one common wiki but contributors can only add to "their" web.

-- TorbenGB

I think you could write a plugin which checks the POSTed email address / REMOTE_ADDR in the initPlugin, and thus to reject the registration attempt (just redirect to a topic explaining it..).

This idea could also be extended to add an admin confirmation step, though that'd be a tiny bit more convoluted :/

Additionally, you could use the REMOTE_ADDR in the initiPlugin to remove the registration_supported or registration_enabled context's, which then disable the registration form for that user..

-- SvenDowideit - 10 Apr 2009

I seem to recall some proxy might paste in the client's IP as X_FORWARDED_FOR in place of its own REMOTE_ADDR.

(But it's late, I'm sick, so I may be confused.)

-- NathanDye - 13 Apr 2009

My Apologies if opening this up again was not the right way to address this, but it is the closest thing I have found on the site that pertains to my question / request, and I figured having everything together makes sense. I also didn't really find an answer to the problem or request above.

With regards to forcing approvals for new users, I think there might be a simple solution... when a person submits a new registration, they are sent to a confirmation screen that tells them to check their emails for the link and confirmation code.

A simple solution would be to NOT send the confirmation code to the user and instead only send it to the wikimaster (or some other programable email address.) This way, the only way a user gets confirmed is if the wikimaster clicks on the link. The user will then get their normal registration confirmation.

For the user experience, the confirmation code page can be replaced with a page that tells them to expect a confirmation in the email in 24 or 48 hours. This page is of course editable by the wikimaster/admin.

Parsing through and understanding the .pm files are beyond my skill level, though editing them with some guidance isn't.

Can someone point me in the right direction where I might control the mailing out of the confirmation emails from a new registration request?

-- KiltBear - 22 Jan 2010

Hmm. I have always thought that adding an approval step for registrations would require an additional step and much more code, but you are right, we actually could implement such a feature simply by changing some strings in the messages to the user and send the confirmation request email to the administrator.

The email that gets sent to the person wanting to register is defined in a template. It is located in registerconfirm.tmpl.

The first few lines of this says

%{ This is a default template }%From: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
To: %FIRSTLASTNAME% <%EMAILADDRESS%>
BCC: %WIKIWEBMASTER%
Subject: %MAKETEXT{"How to activate your [_1] registration" args="%WIKITOOLNAME%"}%

If you remove delete the To: line and change the BCC line to a To: it is the WIKIWEBMASTER that receives the request to confirm the registration.

To make it more elegant you would also change the content of the email so the administrator would get a proper email with information about the guy that wants to register.

The entire template could look like this (without the MAKETEXT assuming your tailored version written in the language of your choice.

%{ This is a default template }%From: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
To: %WIKIWEBMASTERNAME% <%WIKIWEBMASTER%>
Subject: Registration request on %WIKITOOLNAME% for %FIRSTLASTNAME%, %EMAILADDRESS%
MIME-Version: 1.0
Content-Type: text/plain; charset=%CHARSET%
Content-Transfer-Encoding: 8bit

User %FIRSTLASTNAME%, %EMAILADDRESS% has requested registration on %WIKITOOLNAME%

To approve the registration %SCRIPTURL{"register"}%?action=verify;code=%VERIFICATIONCODE%

To reject the registration send an email to the requester or aimply ignore the request.

We need to make one more step.

The requester will be guided to a webpage where he must enter the verification code. We need to change this to a message saying that his request requires approval.

This screen is defined as a message in the file templates/messages.tmpl and looks like this

%TMPL:DEF{"confirm"}%
---+++ %MAKETEXT{"Thank you for registering"}%

%MAKETEXT{"Your activation code has been sent to [_1].  Either click on the link in your e-mail or enter the code in the box below to activate your membership. (This code is of the form \"YourName.xxxxxxxxxx\")" args="%PARAM1%"}%

<form action="%SCRIPTURLPATH{"register"}%" method="post">
<input type="hidden" name="action" value="verify" size="20" />
<input type="text" name="code" size="20" />
<input type="submit" class="foswikiSubmit" value=' %MAKETEXT{"Submit"}% ' />
</form>
%TMPL:END%

We can change this to something like

%TMPL:DEF{"confirm"}%
---+++ %MAKETEXT{"Thank you for registering"}%

Your request has been sent to the administrator who will normally approve your registration within 1-2 working days.
%TMPL:END%

Remember.

Both the messages.tmpl and the registerconfirm.tmpl will be overwritten when you upgrade Foswiki. So make sure that you

Have copies of the modified files in a safe place
Keep a document with a complete list of all the tailoring you have done on your site. This will help you when you upgrade. You cannot remember what you have done just a few weeks after. Keeping a list of the changes and the files changed will make it easy to remove the files or modify the files when you upgrade.

I have not tested any of the above so please report back to us if it works and modify this if needed.

I am sure it will work

-- KennethLavrsen - 22 Jan 2010

Congratulations KiltBear and KennethLavrsen for this! It should be tested and added to distributed documentation.

-- GilmarSantosJr - 22 Jan 2010

KennethLavrsen, you are the awesomest of the most awesome. Thank you for the lightening fast response.

Is there any reason that I can't use the standard skin mechanisms to make make a registerconfirm.moderated.tmpl for example?

Either way, I will be giving this a go today to see how it turns out. My sincerest appreciation.

UPDATE: I had to edit the original template files. I think my problem was I tried to only have the one definition in messages.tmpl and it did not pick up the rest... don't have time to totally suss it out right now. However, the process works fabulously.

One note, is I think when you confirm a registration, it also logs in that user at the same time. That gets a little weird for the administrator clicking on the link.

-- KiltBear - 22 Jan 2010

I recorded this as Faq12

-- CrawfordCurrie - 28 Jan 2010

It would be useful if the administrator could select which behaviour they want using configure

-- MartinCleaver - 09 Feb 2010