Tags:
create new tag
, view all tags

Patch Now Available, see my (KevinAtkinson) comments below.

  • Thanks, Kevin, for that patch. It has introduced an optional step in which a user's email address is verified before a registration is accepted. In 2002. In the meantime this has made it into the core of TWiki.
  • Time passed. In 2005 people seem to want an additional step in which an administrator has to approve a registration. See below for my ideas on that. -- HaraldJoerg - 09 Nov 2005
    • Time continued to pass. Which is, basically, its job. The patch attached to this topic doesn't work with the current Beta DakarRelease, and I'm unlikely to work on it again before Dakar is finished because there hasn't been feedback on this implementation. Perhaps it isn't relevant any more?
      -- HaraldJoerg - 09 Jan 2006


I run a public site for the village in which I live.

A concern of my friends is that, while fantastic that anyone can alter the site, they really would like to be sure of the identity of that user.

The steps would be:

  1. Applying User goes to TWikiRegistration, fills in form including email address
  2. TWiki mails user and gets them to reply
  3. Account is set up once user replies

This at least makes sure that their email address is valid.

For the public site for village with small population it might even be practical to have:

  1. Applying User goes to TWikiRegistration, fills in form including telephone number
  2. Registrations Manager rings user and validates them somehow
  3. Registrations Manager clicks on approve user
  4. TWiki mails user and gets them to reply
  5. Account is set up once user replies

Has anyone already done this? I imagine that it is a variation of WorkFlow. Thanks!

-- MartinCleaver - 29 Mar 2001

Ia am running a small site for my students and a couple of colleagues at Rome 1 University ... I am rather happy with the scheme:

  • register yourself
  • show me your ID
  • I enable you for editing

(I could not trust a phone call or an email reply)

-- AndreaSterbini - 29 Mar 2001

Of course, that will work great for the village! Thanks, I had not thought of that.

At work, I would still like the email verification (potentially 1000s of users, all trustable).

It could be that TWiki sends them a mail with a token that can then be used on the site to enable the account. Anyone that done that?

-- MartinCleaver - 29 Mar 2001


What has happened regarding this? What Martin recommended first can be hacked onto what we have now pretty straightforwardly, given this extra "twist":

  • user registers, giving name and email
  • TWiki emails user to verify email address
  • user hits "reply", "send" (just like Mailman and many other authentications)
  • user is added to UsersGroup when TWiki gets the email back
  • WebPreferences can "Set ALLOWWEBCHANGE = UsersGroup"

-- PaulReiber - 19 Jun 2001

Since I wrote the email I found that it is even more ýmportant in a corporate system. Without it someone can impersonate someone very important (VIP) simply by giving an email address that 1) won┤t bounce (thus not attracting attention) and 2) using the VIPs name.

If the VIP never logs in, no one might ever know.

-- MartinCleaver - 19 Jun 2001

Attached is a patch to support email confirmation. When a user registers an activation code is sent to them via there email address which they are then required to enter in before there account is set up.

To use it a new directory writable by the register script must be created. It should be obvious what to do by looking at TWiki.cfg.

Please test it out and be sure to let me know what you think.

-- KevinAtkinson - 26 Jan 2002

Great, many thanks for the contribution. At present I have I'll try installing it as soon as possible but I doubt that this will be for a few weeks yet (see my profile).

Perhaps someone else can test it and give feedback? It would be nice to see it in a release.

-- MartinCleaver - 30 Jan 2002

My web site with this patch applied plus UserWeb is now available at http://www.ibiblio.org/kevinamm-bin/view. The module I used, Storable, for storing the user data is only standard in Perl 5.6.1 and better by the looks of it as I had to install that module to get it to run on ibiblio which uses perl 5.6.0. I also had to comment out the line

   eval "use Log::Agent";
in order to get everthing to work. Other than that I had no other install problems when I moved my TWiki site from my home machine to ibiblio.

-- KevinAtkinson - 31 Jan 2002

This is important for the TWikiMission - in a corporate intranet, SoftSecurity only works if you can prevent impersonation or pseudonymous userids.

-- RichardDonkin - 04 Feb 2002

I've just played with this a bit more. Nice job Kevin!

Only one comment:

  1. you misspelt 'has' as 'hase' on the oopsregform template.

It would be nice to see this as standard in the BeijingRelease.

-- MartinCleaver - 06 Feb 2002

Well I guess someone should fix that. I am notorious for making spelling errors like that. I try to spell check everthing but sometimes some things slip by.

Also, there are a few things you should know about my code.

The activation code consists of the TWiki Name plus a small random number and the user data is stored in a file based on the activation code. However, when generating a code there is no check done to see if there is already someone by that TWiki name who has not confirmed there email. This means that it is entirely possible for two different people to register at the same time and both get an email with an activation code. However, only one user will be able to activate there account which may tick off the other user just a little bit. All bets or off if both users happen to activate there account at the exact same time. Finally there is the slight possibility that both users would get the same activation code. If this happens my script would blindly overwrite the file containing there information therefore effectively replacing one users information with another.

The probability of any of these events happening is low, but nevertheless, you should be aware of them.

I also believe that allowing multiple activation codes on the same TWiki Name should be allowed as it will give a user a chance to try again if there mistyped there email address or such. However, something should probably be done about the race condition and the overwriting of activation code files.

Also, if you run a popular public site there is a good chance you will get a lot of users who register but never activate there code and thus clutter your hard drive with lots of unnecessary little files. There should probably be some sort of script which will remove all files older than X from time to time to keep the spool directory from getting cluttered.

Finally I only use the Storable Perl module to store the users information to a file a then retrieve it back when they enter the correct activation code. If using this module presents a problem all that needs to be done is to replace those two lines of code with something else which does the same thing. Data::Dumper is not acceptable because it involves evaluating Perl code from a file which is based on user input therefore presenting a huge security hole.

-- KevinAtkinson - 06 Feb 2002

Kevin, I just tried applying the patch to the december release - most of it went in but a couple of things failed. I will upload the bits that failed when I'm not behand a firewall. Was the diff against a Dec 01 release? If not, could you please generate a new patch? I'd really like to see this become a standard feature.

Peter/Main.CoreTeam, Would this be acceptable as a core feature of TWiki? Or do you can see it only as a plug-in?

-- MartinCleaver - 23 Apr 2002

Another reason this is important is as a counter to the increasing amount of automated SPAMMING engines. Sooner or later someone is going to start automating account creation on Wikis. Without a means to do some sort of verification, it would be possible to litter a Wiki with all sorts of garbage.

Peter/Main.CoreTeam, Would this be acceptable as a core feature of TWiki? Or do you can see it only as a plug-in?

-- MartinCleaver - 25 May 2002

Some sort of optional approval should go into the core. A flexible solution is a confirmation defined by a APPROVEREGISTRATION preferences variable:

Set APPROVEREGISTRATION = What it does:
(empty) no approval needed (current spec)
applicant Person registering needs to reply to the confirmation e-mail
manager@my.employer.com Approval is required by listed e-mail address
applicant, manager@my.employer.com Approval from more then one party is possible

-- PeterThoeny - 25 May 2002

Another excellent feature, right to the point for corporate intranets! Couple ideas, by importance (to me):

  1. approval by one person: WikiName is preferable, IMHO. So if I change my email address, there is one place to change it for all usage in TWiki.
  2. approval by group: it is by any one person from a group, maybe UserApprovalGroup is more wiki-like solution.
  3. self-confirmation by replying to email: IMHO better name might be self or reply instead of applicant.
  4. for no approval needed: none, to remind admin what will happen, instead of empty value.

-- PeterMasiar - 25 May 2002

Good points. A restrictive environmnet might require e-mail address verification and user approval, so both should be supported. Revised table:

Set APPROVEREGISTRATION = What it does:
none (or empty) no approval needed (current spec)
reply Verification of e-mail address is required
AnyTWikiUser Approval is required by listed person
AnyTWikiGroup Approval is required by any member of the listed TWikiGroup
reply, ManagerGroup E-mail verification and approval can be combined

-- PeterThoeny - 28 May 2002

Last night we hacked SSL certificate authentication using mod_rewrite to turn the certificate DN into a appropriate username (currently their email address). What I would like to see is an autoregister function so that when a user successfully authenticates via certificate, ldap, SecurID, or carrier pidgeon their ID could automatically be created if it dosen't already exist. This would be very useful for Intranets and possible even extranet's.

The mod_rewrite is not for the faint hearted and it would be nice if TWiki's auth modules had a hook for rewriting certificate DN's (or LDAP DN's, etc) for authentication. If TWiki could autoregister from existing Data Sources such as certificates, NIS, LDAP then rapid deployment would be trivial. A configuration option could be set on whether new users need to be approved or not by some group or individual. This would make rapid deployment trivial!

-- SteveNeruda - 02 Jul 2002

I think this should be looked at again, this time for Dakar (unless Cairo takes too much longer). Has anyone got recent experience with this?

-- SvenDowideit - 15 May 2004

Updated progress fields with values from old manual "Nice to Have" table. Don't know how accurate they are.

-- SamHasler - 08 Sep 2004

What's the status of this? Is there anything more than the patch below? Has anyone done any additional work on the APPROVEREGISTRATION parameter?

-- DougAlcorn - 21 Apr 2005

RegisterCgiScriptRewrite pretty much sums it up: in DakarRelease there exists confirmation of email address by user but not approval by the administrator. I was funding the rewrite out of my own pocket and at the end of the day I decided that APPROVEREGISTRATION was beyond my needs.

There are thus two options going forward:

  1. Anyone is welcome to welcome to email me re: GettingPaidToDevelopTWiki - I could make it do what you want.
  2. I'm happy to advise you on what you (or your contractor of choice) needs to do to make it work.
  3. Consider that you might actually be just as happy with a BulkDeleteUser function instead of ApprovingRegistrations

-- MartinCleaver - 22 Apr 2005

On an Internet Wiki, there is the hassle of spamers .... this led to discussion on TWiki-Dev and to the subject of approving or filtering registration. This is my observation and thoughts, transcribed from e-mail:

Administrators can't afford the time to verify and approve each registration, so this has to be automated. The HOW it gets automated is ... well, probably site dependent.

We're talking Big-I Internet here, right? Because on a corporate intranet its a different issue. q.v.

What is needed is a Hook where the admin can plug in a (site specific) verification tool.

Example #1:

One of the sites I administer is restricted to people who are on a mailing list. They must register with the same e-mail address they use on the list and the list admin sends the list in every month or every change. The verification is a simple grep against that list. It can be done at the time the registration is submitted.
This is fully synchronous.

The hook is straight forward and does not alter the present flow of control. Failure of the grep merely aborts the registration. Examples of this are in Register.pm. q.v.

Almost synchronous variations on this may involve querying a 'remote' database, where 'remote' may be another server on the LAN (read LDAP) or across the Internet.

Example #2:

This also verifies the E-mail address but the wiki is an 'open' rather than a restricted one and hence a prime target for spamming since anyone on the Internet can quite validly register. The verification here is to address the spammers who use false addresses.

Domain lookup of the submitted e-mail address can be done synchronously. If the domain does not exist the registration is aborted. This does not alter the flow of control.

To verify the e-mail address does involve altering the flow of control. The 'obvious' approach is to send a message to that address and if it fails abort the registration. However it may not be possibly to do this synchronously. A synchronous approach would have a SMTP process; an asynchronous one would actually send mail and wait for a reply or a response from the MTA saying that the message was undeliverable. Both have their complications.

The asynchronous method breaks the current flow of control. The registration information must still be recorded but until the verification is done the mail asking the user to verify cannot be sent. Or perhaps 'should not be sent'.

Additional Case:

In a real world situation it is likely that access to parts of the Wiki can be further restricted. Making most of the Wiki only accessible to members of a particular group would mean that spammers who did register and were not placed in that group could have limited access and hence impact.
(Yes, I know this is in contradiction to most of the "Wiki Philosophy".)
(Yes, I know that they can still put the URL in their registration.)

However we have only really moved things along one step. Now, instead of of verifying to allow registration, the administrator must verify before adding to a group.

It does highlight a couple of points - that an automated way of adding a user to a group as well as a simplified UI for manual group maintenance is needed.

-- AntonAylward - 07 Nov 2005


I have managed to get a new registration workflow containing approval running based on Dakar SVN code. New parts are marked green , possible future enhancements towards pluggable registration in red .

  1. NewUser fills TWikiRegistration
  2. TWiki checks configuration whether NewUser has to verify his email address or, more generally, how to validate form data. This method can be overridden by a registration subclass.
    • if yes if predefined hook 'validate email address'
      1. send mail to NewUser containing a code (random password)
      2. respond with an oops explanation and a form to enter the code
    • if custom hook, call custom hook which can either redirect to its own oops template or just return after successful validation
    • if no:
      1. TWiki checks configuration whether %WIKIWEBMASTER% has to approve the registration or, more generally, which offline procedure has to be performed
        • if yes if predefined hook 'ask webmaster'
          1. send mail to %WIKIWEBMASTER% containing an approval code (random password)
          2. respond with an oops explanation asking NewUser for patience until he receives the confirmation mail
            • Time passes.
            • Time continues to pass.
          3. %WIKIWEBMASTER% enters the code to approve NewUser's registration
          4. TWiki creates NewUser's home topic (the blue steps are is existing code!)
          5. add NewUser to Main.TWikiUsers
          6. add NewUser to the password management
          7. send mail to NewUser and %WIKIWEBMASTER% to inform about the registration
          8. unlink the saved files in data/RegistrationApprovals
          9. respond with an oops thank you to %WIKIWEBMASTER% for his work.
            • Time passes.
            • Time continues to pass.
          10. NewUser reads the confirmation mail and logs in.
          11. NewUser happily starts editing topics.
        • if custom code given: Call custom code which is likely but not required to use the oops response from step 2 from the predefined hook
        • if no:
          1. Do all the blue steps from above
          2. install cookies
          3. enter authenticated context as NewUser
          4. respond with an oops thank you to the user
          5. NewUser happily starts editing topics.

Note that the need for an admin's approval creates workflows for two different instances, NewUser and %WIKIWEBMASTER% and therefore introduces a break of undefined length from the view of NewUser.

Coding is done, unit tests are mostly implemented (added approval without and with verification), oops templates written. I18N is yet to be done, and there's one known fixed bug plus an unknown number of unknown bugs. svn diff | wc counts something 900ish lines. Since I'm going to work on different things in the next days I'll attach the diff in case anyone is desperate enough to try it. Unit tests pass, some of the TestCases don't, but I am pretty sure that I am not to blame for TestCaseAutoSearchOrder or TestCaseAutoTagFromTags failing.

During the manual tests I stumbled over a couple of usability questions where I would welcome feedback of experienced TWikizens before I start with the final 10% of work (which, as we all know, consume the final 90% of time).

  1. Is %WIKIWEBMASTER% the correct instance for approval? I've simply adopted that from the current workflow where %WIKIWEBMASTER% gets a copy of the registration thankyou message. Should it be - as suggested in the three-year-old discussion above - a member of a TWiki user group instead? Or a member of TWikiAdminGroup in particular?
  2. As an admin, I'd highly welcome a topic listing all registrations waiting for approval. The analogy to BulkRegistration would indicate that approval should be done by TWikiAdminGroup instead of %WIKIWEBMASTER%.
    • Should we continue to send mail to the members of the group? If members of TWikiAdminGroup are WebNotify-ed about changes in %MAINWEB% this is just a duplication of information. I'd suggest we do send mails, even if this adds to the amount of code to be done (read group topic, extract mail addresses, ...) All stuff done elsewhere in TWiki code, it's just a matter of copypaste, but quite a job to do for test cases.
    • By duplicating the access restriction of BulkRegistration to approval we could get rid of the approval random password which I have implemented, not being extremely happy with it.
    • What happens if several admins start approving users at the same time? Race conditions are lurking....
  3. Should it be an option for bin/configure (like NeedVerification) or, as written above, a TWikiPreference? I have implemented an option for bin/configure for symmetry reasons right now, but am still confused about the separation of jobs between these two.

-- HaraldJoerg - 09 Nov 2005

In http://twiki.org/cgi-bin/view/Codev/WikiSpam, CrawfordCurrie suggests:

Additional gear agains WikiSpam:
   1. reject registrations with email addresses matching @126.com (and others) in =bin/register= 
Which gets back to the point I have made in a number of places (including IRC) that we need a "hook" for external validation in a number of places, one of them being on submission of the form.

-- AntonAylward - 10 Nov 2005

Absolutely agreed. On the road towards pluggable registration, what I've done here is just a sidestep. One which has been discussed pretty often recently. So before I start to develop a plugin mechanism for registration hook I'd like to have an agreement about the workflow into which we are hooking. We need to get the hook's configuration and API right. The implementation I've chosen would allow to add an arbitrary number of validation steps. For example, the sequence of validation and approval can be exchanged by exchanging one single line in Register.pm (untested ;-)). I've added my intentions for future work in the workflow above in red .

-- HaraldJoerg - 10 Nov 2005

I've been asked how confident I am in my code since there hasn't been any discussion. The answer is simple: It simply doesn't work with current Beta releases of Dakar due to some of the several hundreds of patches applied to Dakar. I'm unlikely to work on this again before Dakar is released.

-- HaraldJoerg - 09 Jan 2006

So what's the status of these Changes? For an intranet-site available through the internet it's extremely usefull to have someone to approve user registrations I think.

-- JanLuebbert - 09 May 2006

Is there any effort taking place for this to continue? Just sending 2 e-mails 1 to new user, and 1 to site admin(s) - let 2+ approver e-mail addresses be defioned... It would be soo helpful in keeping the barbarian bastages at bay!

-- ToddGrayson - 25 May 2006

It might be revitalised when I have to maintain a TWiki in the internet. At the moment I'm running in intranet where approving registrations is exactly what I don't need, and I find it difficult to spend spare time for things I can't use myself. Another problem is that as of today there are nine open bugs in the registration code, and fixing those will take precedence.

But there is hope: I have been asked to set up a Wiki in the internet, and this might be a TWiki smile

-- HaraldJoerg - 31 May 2006

One "quick and dirty" workaround for registration approval might be to change the destination of the current verification email. It could be sent to the members of the TWikiAdminGroup rather than to the registrant. Once someone in TWikiADminGroup felt that the registration was legitimate they could forward/redirect the email to the registrant who could then complete the registration process.

Obviously this is not a "full featured" solution, but I think it is viable as a short-term or mid-term solution for the TWiki I am currently setting up. Any thoughts on this and how I might go about making it happen (i.e. where do I make the appropriate code changes)?

-- RocklynClarke - 18 May 2007

Yes, the same work-around also occurred to me and I'd also be interested in the answer to the question that RocklynClarke has asked. Thank you to the kind person who provides us with the insight smile

-- KeithHelfrich - 18 May 2007

I just cross-posted my earlier "quick and dirty" workaround question in HowToDivertRegistrationEmail. Naturally, I will cross-post any answers that I receive.

-- RocklynClarke - 18 May 2007

Based on a suggestion from someone else on this site, I achieved the result I was looking for by modifying the templates/registerconfirm.tmpl template. This is the template that generates the confirmation email. I modified the "To:" address to send the email to the TWiki administrator and I modified the contents to provide instructions to the administrator for how to edit and resend the email to the intended registrant.

-- RocklynClarke - 23 Jun 2007

Rocklyn, that's a great solution. Note that it would be straightforward to bundle up your modified templates and topics in a zip for other people to also share.

Longer term a better solution would be to use a skin to select an alternate mail template. I don't think that's so easy at the moment, but with a minor code change or two it could be (if the demand was there).

-- CrawfordCurrie - 24 Jun 2007

I designed the underlying system to send a token to the user to verify the user. The same capability can be used to then send a token to the administrator. Once I get a client that wants this I will implement it: I have one in mind.

-- MartinCleaver - 02 Oct 2007

Greetings! Has anyone made further progress on this ? I'm headed now to put in the manual workaround ..

-- KeithHelfrich - 23 Dec 2007

well, one way to achieve this, is to use AddUserToGroupsOnRegistration to add users to a limited access group. Then the Admin / other Wiki Users/Gnomes can move approve them my moving them to other groups.

-- SvenDowideit - 26 Dec 2007

now I want it the other way around wink I'm really happy with the manual hard-coded email address to the admin for ApprovingRegistrations ... but I'm wondering how I can AddUserToGroupsOnRegistration at the time of approval... ? Maybe the confirmation mail that is sent to the admin could include different links to click ..

  • click this link to approve & add to XYZ group: http://_____
  • click this link to approve & add to ABC group: http://_____

Would that work ? If so, how to construct those URLs ?

-- KeithHelfrich - 12 Mar 2008

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff ApprovingRegistrations_7408.diff r1 manage 33.3 K 2005-11-09 - 22:12 HaraldJoerg Dakar-based admin approval of registrations
Unknown file formatdiff ApprovingRegistrations_7425.diff r1 manage 34.2 K 2005-11-10 - 22:12 HaraldJoerg Dakar-based admin approval of registrations (with registerapprove template)
Unknown file formatdiff email-confirm.diff r2 r1 manage 14.9 K 2002-01-27 - 05:52 KevinAtkinson Patch to enable Email Confirmation
Edit | Attach | Watch | Print version | History: r50 < r49 < r48 < r47 < r46 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r50 - 2008-08-17 - RafaelAlvarez
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.