Extension talk:ConfirmAccount/archive 1

Disable the email sending
Hi, I'm using this extension to create a login system that requires the users to have the account checked, but I don't want to use the email part of it. Is there a way of taking that section only out of it? -CustomJ 14:37, 7 December 2007 (UTC)

Send account request to Administrator
After a new user confirmed the e-mail of his account request, the administrator receive an e-mail notification about this pending request with a direct link to Special:ConfirmAccounts. Tested in english an german.

Patch function in extensions/ConfirmAccount/ConfirmAccount_body.php
function confirmEmailToken( $code ) { global $wgUser, $wgOut; # Confirm if this token is in the pending requests $name = $this->requestFromEmailToken( $code ); if( $name !== false ) { # Send mail to admin after e-mail has been confirmed global $wgEmergencyContact; $u = User::newFromName( $name, 'creatable' ); $u->setEmail( $wgEmergencyContact ); $title = Title::makeTitle( NS_SPECIAL, 'ConfirmAccounts' ); $url = $title->getFullUrl; $u->sendMail (wfMsg('requestaccount-email-subj-admin'),                               wfMsg('requestaccount-email-body-admin', $name, $url)); $this->confirmEmail( $name ); $wgOut->addWikiText( wfMsgHtml( 'request-account-econf' )); $wgOut->returnToMain; return; }               # Maybe the user confirmed after account was created... $user = User::newFromConfirmationCode( $code ); if( is_object( $user ) ) { if( $user->confirmEmail ) { $message = $wgUser->isLoggedIn ? 'confirmemail_loggedin' : 'confirmemail_success'; $wgOut->addWikiText( wfMsg( $message ) ); if( !$wgUser->isLoggedIn ) { $title = SpecialPage::getTitleFor( 'Userlogin' ); $wgOut->returnToMain( true, $title->getPrefixedText ); }                       } else { $wgOut->addWikiText( wfMsg( 'confirmemail_error' ) ); }               } else { $wgOut->addWikiText( wfMsg( 'confirmemail_invalid' ) ); }       }

Translation file
Get the translation file from rrosenfeld at http://www.spinnaker.de/tmp/ConfirmAccount.i18n.php.txt and extend the english and german section:

English section: 'requestaccount-email-subj-admin' => ' Request account', 'requestaccount-email-body-admin' => 'The account "$1" has request an account and is waiting for confirmation. The e-mail address has been confirmed. You can confirm the request here "$2".',

German section: 'requestaccount-email-subj-admin' => ' Antrag auf Account', 'requestaccount-email-body-admin' => 'Das Benutzerkonto "$1" hat einen Antrag auf einen Account gestellt. Die Emailadresse wurde bereits bestätigt. Du kannst den Antrag unter "$2" freischalten.',

regards --schweny 22:50, 13 August 2007 (UTC)

Extension don't work in opera/IE
When I press "Request account" button in Opera/IE/Konqueror page only reloads and nothing happens (I'm using latest version of MediaWiki).

What do you think about this ugly bug?
 * Works fine for me. Aaron 19:23, 26 August 2007 (UTC)
 * Very interesting... ;) I'm checked the source and found that this line returns false:

$wgUser->matchEditToken( $wgRequest->getVal( 'wpEditToken' ) )
 * I have tested it in IE 5, Opera 9.23 (under linux), Konqueror 3.5.6 and Firefox 2.0.6. And only in Firefox all works fine :(
 * I fixed some fucked up non-XHTML valid html. Maybe it will work for you now. Either way, it worked on IE 7/Opera 9.2/FF 2.0.6 for me. Aaron 06:27, 27 August 2007 (UTC)
 * I am having the same problem as the first fellow. Can you post the revised html so that I do not have to reload the entire extension?  Thanks.  8 September 2007.
 * We are also having these problems - they don't seem to be browser-related, and are difficult to replicate. But some users in some places, on trying to request an account, it doesn't seem to execute and stays on the account registration page. Aaron, can you help? - Jtneill 01:29, 4 October 2007 (UTC)
 * Note further discussion is also available on User_talk:Voice_of_All - Jtneill 01:39, 4 October 2007 (UTC)

Spam prevention?
For people using this, does it help with spam prevention? I just added a capatcha script but I'm looking at my user list and there are a lot of spam generating user names on there. Has it helped cut down on spam or does it seem to deter legitimate users? --76.214.233.199 17:51, 27 September 2007 (UTC)
 * It doesn't hurt, since if it's only for creation it's a one time think. This extension is mainly for open sites that want at least halfway trustworthy users (or PhDs, whatever criteria they use to confirm). If the throw away accounts don't actually edit anything, then I'd leave it alone. If spam keeps appearing, I'd try another extension first, with anon-page creation disabled (if not already). If that fails, then try this. Aaron 18:39, 27 September 2007 (UTC)

Working all right so far
We finally installed this and it's working excellently so far! --Larry Sanger

Send account request to list of users
Here is a modification, based on Sschwengel's modification. It will send an email notification to all users specified in the array, rather than to just the administrator. To use this code, place it in the same location as Sschwengel's code.

Nynexman4464 21:23, 13 October 2007 (UTC)


 * Anyone have any suggestions on getting this mod to work? I've added the above code into the ConfirmAccounts_body.php and I've tried putting the  array in the LocalSettings.php and at the top of ConfirmAccounts_body.php, but nothing I've tried will send an email to the specified address. I've also thought that the array should list the wiki username and use the associated email address, but that didn't work either. Here's my array. What am I doing wrong?
 * Takieyda 00:32, 25 October 2007 (UTC)
 * Progress. At first I wasn't including Sschwengel's code in my ConfirmAccount_body.php. After inserting that in as well as Nynexman4464's code and placing the $wgUserAccountRequestNotifTargets array back in the LocalSettings.php file I'm now receiving emails after the user confirms his email. The problem now, though, is that the email contents come as:
 * Subject  &lt;requestaccount-email-subj-admin&gt;
 * Body     &lt;requestaccount-email-body-admin&gt;
 * Takieyda 19:39, 25 October 2007 (UTC)
 * Ok, I fail at reading comprehension. I just needed to add the lines from Sschwengel's post about the internationalization file and things worked.
 * Takieyda 21:34, 25 October 2007 (UTC)
 * Takieyda 21:34, 25 October 2007 (UTC)

Question : where do you insert Sschwengel's code in the ConfirmAccount.i18n.php file ?

 * I tried to follow his suggestion but got error message. -- Daniel
 * This patch worked for me: --Arnd 11:00, 26 October 2007 (UTC)

Eliminating ToS checkbox
I don't need the checkbox at the end of the RequestAccount-page. A quick look in the sourcecode let me assume there is a boolean preference variable for this (something with ToS for Terms of Service?!), but I'm missing the documentation. Can someone give me the name of that variable or a hint on how to find it (see snippet from ConfirmAccount_body.php below):

$this->mToS = $wgRequest->getBool('wpToS');

Thanks, --Arnd 06:50, 25 October 2007 (UTC)


 * Forget this, I took a deeper look into the source-code and recognized there is no such variable. Therefore I implemented some (see the following chapter).

Patch make the RequestAccount-page more flexible
As I wrote above, I do not need such ab big RequestAccount-page with so many text-fields. In order not to discourage my potential wiki users from submitting an account request, I introduced some more variables to switch off several parts of the page:

With this patch applied to ConfirmAccount_body.php (version: r26938)
 * $wgAccountRequestToSEnable enables "the Terms Of Service"-checkbox at the bottom of the page (if set to true)
 * $wgAccountRequestExtendedInfo enables the second field with the resume-upload, web-pages and so on (if set to true)
 * Additionally, the Upload-File text field is hidden if $wgAllowAccountRequestFiles is set to false (since it is of no use in this case).

Please mind that both, $wgAccountRequestToSEnable and $wgAccountRequestExtendedInfo, are treated as false by default, since I did not include a default setting in SpecialConfirmAccount.php. So it's best to include them in your LocalSettings.php, independent from their value.

Aaron, I would appreciate if you would review my patch and maybe include it in your extension. Please excuse my mistakes (if any :-) ), but I'm not familiar with neither php nor mediawiki extension programming. Never the less I think it's important to make the RequestAccount-page more flexible (in particular with the new features you just implemented) so that new users don't get scared by all these informations they have to provide just to get access to a small wiki (which it is in my case but may not be in others).

--Arnd 14:45, 25 October 2007 (UTC)
 * I've added pretty much the above functionality now. Aaron 17:34, 25 October 2007 (UTC)


 * they are named:

Bug in ConfirmAccount.sql
There is a bug in ConfirmAccount.sql in version r26938 which lead to failure message from mysql while the table was created (at least in my installation). The following patch solved this for me:

--Arnd 14:45, 25 October 2007 (UTC)
 * Fixed. Aaron 17:18, 25 October 2007 (UTC)

Typos in ConfirmAccount.sql
URL: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/ConfirmAccount Revision: 29095
 * in Line 68,5   acr_id int unsigned NOT NULL auto_increment, acr_ should be acd_
 * in Line 103,22  UNIQUE KEY (acd_id), the koma shouldn't be there

Error when sending mail: 1
I have some troubles that I can debug no further. The mail system seems to work. When I create a new user account, an email is sent.

If I click on the link I get to a page saying that the code has expired even though it has only been generated 10 seconds before. On the account creation page I get an error code 1 - Error when sending email: 1

Even though I have set the debug flag on mail, there are no error messages to be seen in the PHP og Apache log files. Also there are no rows in the special account_creation table in the database.

Anyone?


 * I cannot replicate those errors. Make sure you have the latest version from SVN. Aaron 07:35, 28 October 2007 (UTC)

Well I didn't expect that either.

But what does this error code mean? Is it normal behavior that there are no rows in the SQL-table I mention? Are there any way to get some more debug information out of the system? It would be nice with anything that will enable me to correct what is obviously misconfigured in some way.

Thanks.


 * Try adding the following to localsettings:
 * $wgDebugLogFile = [SOME DIRECTORY]\dbLog.log';
 * $wgLogQueries = true;
 * $wgDebugDumpSql = true;
 * As well as "error_reporting( E_ALL );". Check for PHP/SQL errors. Aaron 18:32, 28 October 2007 (UTC)

Everything seems ok:

SQL: BEGIN SQL: INSERT /* RequestAccountPage::doSubmit 212.242.187.85 */ INTO `mw_account_requests` (acr_id,acr_name,acr_email,acr_real_name,acr_registration,acr_bio,acr_notes,acr_urls,acr_filename,acr_storage_key,acr_comment,acr_email_token,acr_email_token_expires,acr_ip) VALUES (NULL,'Test','.......','Test','20071028231554','test test test test test test test test test test \ntest test test test test test test test test test \ntest test test test test test test test test test \ntest test test test tes Sending mail via PEAR::Mail to ...... SQL: ROLLBACK SQL: BEGIN

No errors in PHP either. I'll guess I have to let it be and not use the module. Shoots. But thanks for your help.
 * SQL: ROLLBACK? That only occurs if the email client throws an error. Rollback reverses the DB transaction, which is deleting the account request. Probably your email client it bugged. Aaron 04:15, 29 October 2007 (UTC)

Problem with Greek Mediawiki
I tried to use this extension with a Greek mediawiki and I added a Greek translation in the internalization file but I get the following message when a someone tries to submit an account request:


 * "The requested page title was invalid, empty, or an incorrectly linked inter-language or inter-wiki title. It may contain one or more characters which cannot be used in titles."

The problem does not occur if I use English in the LocalSettings.php but the minute I revert to Greek I have a problem.

Please let me know if there is something I need to to. Thanks.


 * What title does it set the page to for Greek? It may be something that fails the Title validation regexps. Aaron 19:08, 5 November 2007 (UTC)

I am not sure what title it set's the page to for Greek. All I did to test the functionality was to copy the English translation, paste it in the ConfirmAccount.i18n.php file below the English version and modify $wgConfirmAccountMessages['en'] to $wgConfirmAccountMessages['el']. If it worked I would then translate the messages to Greek. Was this the right strategy? --213.5.191.99 09:03, 6 November 2007 (UTC)

Maybe this is helpful: The address for the Request Account form is the following (where the gibberish stands for Special)

mysite.../index.php?title=%CE%95%CE%B9%CE%B4%CE%B9%CE%BA%CF%8C:RequestAccount

As soon as I hit the submit page I get the following address (and the message "The requested page title was invalid, empty, or an incorrectly linked inter-language or inter-wiki title. It may contain one or more characters which cannot be used in titles."):

mysite.../index.php?title=%CE%95%CE%B9%CE%B4%CE%B9%CE%BA%CF%8C:RequestAccount&action=submit --213.5.142.65 15:53, 7 November 2007 (UTC)

Aaron, I am really eager to get this running on my Greek wiki (it's a great extension)...do I have hope? Any suggestions will be greatly appreciated. Thanks, --213.5.142.65 12:51, 8 November 2007 (UTC)
 * Make the translations and post the patch on bugzilla. That way we could also see the problem. Aaron 03:16, 9 November 2007 (UTC)

Will do. Thanks --213.5.142.65 08:58, 9 November 2007 (UTC)

OK, this issue should be fixed now. It was a general form submission issue that affected several langauges. Aaron 22:24, 8 December 2007 (UTC)

Upload functionality requires MediaWiki 1.11 ?
It seems that the upload functionality needs to instantiate includes/filerepo/File.php, which I see in MediaWiki 1.11, but not 1.10. I get this error when $wgAllowAccountRequestFiles = true:

Fatal error: Class 'File' not found in .. extensions/ConfirmAccount/ConfirmAccount_body.php on line 253

Love all that you're doing with this extension. Jlerner 04:38, 8 November 2007 (UTC) Actually the relavent line of code is not even needed, I'll just remove it when I get the chance, which should add b/c. Aaron 00:24, 5 December 2007 (UTC)
 * OK, I added a blurb now. Aaron 05:05, 8 November 2007 (UTC)

SQL assistance
This is greek to me: '''Run the SQL query, substituting in your wiki's table prefix. ConfirmAccount.pg.sql is for PostgreSQL, and ConfirmAccount.sql is for MySQL.'''

Using PHPMyAdmin how do I do this?

- Elihuwdr 18:25, 13 November 2007 (UTC)


 * Using MySQL, you'd go to "SQL" and paste in the stuff here. Replace /*$wgDBprefix*/ with the real prefix. Then press "Go". Aaron 21:56, 14 November 2007 (UTC)

Customize system messages / Welcome message
In my installation, the content of the "confirmaccount-welc" system message is not included into new users userpage any more, although $wgAutoWelcomeNewUsers is not set to false in LocalSettings.php (default is true). I think this started when I customized this message. Can anybode reproduce this? --Arnd 13:45, 3 December 2007 (UTC)

Emailing Password doesn't work
I'm running MediWiki on an Ubuntu 6 server with Apache, MySQL 5, and PHP 5. I've installed the ConfirmAccount extension, and it works great, except it doesn't ever send the user a password. It does send the user the "Email Confirmation" email, which has the token link where the user's can verify their email, but no email containing the password ever comes through. I'm using Postfix as the emailer on the server. I saw the info in the ConfirmAccount notes that says "if the email client loses its mail data before sending it out, users will not get their password..". Could that be the issue? I've tried using the PasswordReset extension as suggested, but that doesn't email the password either. Any other suggestions on what I might be doing wrong and how I can troubleshoot this? TIA.


 * Sounds like a local configuration issue. Aaron 04:27, 14 December 2007 (UTC)

Any suggestions on what to check for? Should I be looking at my Postfix configs or MediaWiki configs? Any advice on how to troubleshoot this would be appreciated. Thanks. --Bbemis 14:28, 14 December 2007 (UTC)


 * Do you have set $wgEnableEmail = true; in LocalSettings.php? regards --Bpczi 15:04, 14 December 2007 (UTC)

Yes, I have $wgEnableEmail = true... like I said before, email works for the Confirmation email... just not the password reset email. I have figured out a something else though. I tried sending a Password Reset request from my own Sysops account, and it worked, but didn't work for any of the dummy test accounts I had created using the ConfirmAccount extension. If I take one of those accounts and manually assign them to a group (like bot, sysop, etc.) then the password reset email goes through without a problem. So, I think it has to do something with a new account not automatically being assigned to a group when it is created. Is there a setting in there I can change so that all users get placed in a default group? Any ideas? Thanks again. --Bbemis 17:34, 14 December 2007 (UTC)


 * Ok, I stand corrected! It's not tied to the group the user is in... all of a suddent it just started working! Very odd... not sure I changed anything, but it seems to be working for all users now. Hopefully it stays this way :) --Bbemis 18:06, 14 December 2007 (UTC)

$wgRejectedAccountMaxAge doesnt work
MediaWiki: (1.11.0)

Hi!

I am using the extension ConfirmAccount. This extension is great but I have a problem. The variable definition of $wgRejectedAccountMaxAge dont works! Isnt it so, that the value of this parameter defines how long rejected request will be kept? I have defined it in the SpecialConfirmAccount.php: $wgRejectedAccountMaxAge = 1 * 24 * 3600; But in the Special:ConfirmAccount are rejected requests which are older than one day?!

And what about $wgAccountRequestThrottle? I also have set it in SpecialConfirmAccount.php to: $wgAccountRequestThrottle = 1; But I can request endless accounts from one ip adress!

Please help!

Many thanks for your help! --Bpczi 15:14, 14 December 2007 (UTC)


 * Two things, there was a bug from a version a few weeks ago that didn't delete old rejects which was fixed. Also, it deletes based on a random change of 1/100 for each person viewing the confirm accounts page, so some things may stay it bit longer depending. Recent changes is similar about this. Aaron 18:51, 14 December 2007 (UTC)

Hi!

I see! But I have downloaded the extension three days ago from this link. Revision 28506: /trunk/extensions/ConfirmAccount Is this the old version you mean? Maybe you could explain to me how I find out the version i am using and if this is the relevant version which contains this bug!? Thank you for your help! --Bpczi 08:10, 15 December 2007 (UTC)


 * My point is that with the newest version, old requests may still hang around for a while sometimes, because it is purged at random. Aaron 21:18, 15 December 2007 (UTC)

Hi!

First of all many thanks for your help!

Your answer seems to be logical, but i have restarted the server and the client pc on which i am joining mediawiki! There are requets which are more than twice overdue. The oldest requests are from the 12th december, allthough i have configured: $wgRejectedAccountMaxAge = 1 * 24 * 3600; Could that be? As i understand, the requests which are older than one day have to be removed from the list, but they dont do it!

Best regards,

bpczi


 * Try changing the line 'if( 0 == mt_rand( 0, 99 ) )" to "if( 1=1 ) " in the body php file. If you are the only one viewing requests, it is unlikely to prune that often, so that may be your problem. Aaron 18:16, 26 December 2007 (UTC)

Hi!

Many thanks for your advice!

I have changed the line "if( 0 == mt_rand( 0, 99 ) )" as you described, but it doesnt work! After that change I get following error message: Parse error: syntax error, unexpected '=' in ..\wiki\extensions\ConfirmAccount\ConfirmAccount_body.php on line 985

Then I tried to change it to that: if( 0 == mt_rand( 0, 1 ) )

and it works!!!!!!!!!!!!

Many thanks for your help!

best regards,

--Bpczi 19:48, 26 December 2007 (UTC)
 * Opps, I meant "==", not "=", but that way is better so you can change it later more easily. Aaron 21:14, 26 December 2007 (UTC)

Feature requests from the Citizendium
First, well done on the "currently being viewed by" feature!

All, I am so glad to see that there are people helping Aaron with this extensionm, which is very useful and important to us. We do have a few feature requests, however. CZ would like to have the option to allow account approvers to do the following:
 * 1) Edit biographies.  (This allows us to remove information about hometowns, age, and school from people under 16 years old, without having to change it and then "oversight" the result.)
 * 2) Allow sysops, or perhaps a higher-level user, to save and view the info entered in "Identity confirmation."  And also CVs (especially--people often apply later for editorship and say, "but I already gave you my CV"--"sorry, but I can't access it anymore").  Currently this is either deleted or not visible, anyway.  Sometimes, we need to see the info in order to decide how to handle a specific problematic user--we sometimes want to doublecheck someone's identity when considering whether to boot them from the project. In general, we (rarely) need to see the info after an account has been approved.  That info might be added to the user's "block user" (Special:Blockip) page, which we use to locate the person's e-mail address, or else put it all in a new special page...obviously, the possible existence of such a "confidential info" page is one thing that would greatly distinguish CZ from WP.
 * 3) When request approvers use the "hold" and "reject" options, no one else can see the comments entered there.  That's crucial information for mutual oversight and collaboration.  We really need to be able to see that info in the reject and hold queues.
 * 4) Under "Signature" (bottom of the page) we'd like to have actually three separate checkboxes.

We won't be opposed if you want to make these off by default, since they are important mainly for CZ's policies. But we do need these things.

There's another big feature request that we badly need. There are multiple roles in our system: author and editor. Not only would we like a checkbox that someone can check if they're interested in becoming an editor...we'd actually like to go further and create three new queues: new editor applications, editor applications on hold, and rejected editor applications. Note that we'd have to be able to have all the relevant info after an author account had been approved. If anyone is interested in doing this, e-mail me at sanger [at] citizendium.org and I'll send you more detailed requirements.

I'd like to know who is using this extension, just out of curiosity. --Larry Sanger 18:13, 28 December 2007 (UTC)


 * Looks like it is all doable. I was opposed to biography editing, but if a credentials table is added, then it can store the original, so that way we can be sure what they really sent. Aaron 23:32, 28 December 2007 (UTC)


 * Actually, I don't see the point of #4 since even two looked cluttered. Still working on the rest though. Aaron 02:00, 29 December 2007 (UTC)


 * Glad to hear it's doable! Do let me know when you're ready to do the editor system; there are several nonobvious requirements.


 * As to #4, well, we'd just like to make sure people read and understand that there are three things they're agreeing to. This is a lot more important than an uncluttered look.  Besides, for other websites, just one checkbox (or none) could be the default setting. --Larry Sanger 03:19, 29 December 2007 (UTC)


 * Should this credential page be update-able or should it stay as it was during the time of account approval? People can always post their their info and post/link to/upload their resume afterwards and have it on some subpage, and the original "identity" info is fairly private; so I guess this special page would be static then? Aaron 04:48, 29 December 2007 (UTC)
 * I'll just make the schema able to have revisions. Aaron 23:32, 29 December 2007 (UTC)