Extension talk:ConfirmAccount/LQT Archive 1


 * Archive 1

Update
Could you please modify the system message calls in confirmaccount_body.php into these:
 * $wgOut->setPagetitle( wfMsg( "requestaccount" ) );
 * $wgOut->addWikiText( wfMsg( "requestaccount-dup" ) );
 * $wgOut->addWikiText(wfMsg( "requestaccount-text" ) );

That way it would become possible to use Templates in the calls. Thanks! --130.233.141.220 08:13, 19 June 2008 (UTC)
 * Templates in the title? hehe ;) Aaron 00:33, 20 June 2008 (UTC)
 * OK, did the others. Aaron 00:34, 20 June 2008 (UTC)
 * Thanks, enabling that gives a lot of possibilities to config the looks of the account requests etc :-) 83.145.207.200 20:56, 10 August 2008 (UTC)

Localizing account creation look and feel
It strikes me that editing the account creation text would be one of the most desired things to do, even for an administrative newbie like me who has no Template management experience at all. Personally, I would welcome in this discussion page some brief elementary best practices (or a link thereto) for simple changes to the distributed message text, in ways that might minimize pain should I fetch a later version of ConfirmAccount. For example, if I simply want to add or change some text to one of the fields in $wgConfirmAccountMessages, is the proper route to adjust that field in LocalSettings.php? --Bob 13:52, 23 August 2008 (UTC)

By the way, in v 1.41, there is message text "submited" where "submitted" is intended. Also a few fields in $wgConfirmAccountMessages have names beginning with "requestacount" instead of "requestaccount". I can imagine this could cause pain, no matter how brief, for someone who didn't notice that when coding against it. --Bob 13:52, 23 August 2008 (UTC)


 * Late answer: try to find the string you want to modify in the ConfirmAccount folder in the file ConfirmAccount.i18n.php. For example, to modify the legend "Personal information" search for this string, finding the key 'requestaccount-leg-person' in front of it. Go into the wiki and modify the URL of a page, changing the page name to, e. g., "MediaWiki:Requestaccount-leg-person". Modifying the content of this page will change the string that is used in ConfirmAccount. --G.Hagedorn 21:32, 11 December 2008 (UTC)

What to do with previous users
I got this trying to connect : « wfConfirmAccountsNotice ». MySQL a renvoyé l’erreur « 1146 : Table '12345.wiki_account_requests' doesn't exist (localhost) », probably due to that my own Username hasn't been checked yet...--NewMorning 21:58, 28 June 2008 (UTC)
 * Sounds more like you haven't made the tables in ConfirmAccount.sql. FunPika 22:05, 28 June 2008 (UTC)
 * True : had not carrefully red : "Replace /*$wgDBprefix*/ with the proper prefix"
 * Many thanks, --NewMorning 11:39, 29 June 2008 (UTC)

Default settings for config options?
What are the defaults? It would be nice to know to stop the config getting cluttered ;-) --Dmb 16:52, 30 July 2008 (UTC)
 * D'oh! "The default values are in SpecialConfirmAccount.php" - Perhaps this text could appear first? (its a big list...) hrm... that gives me an idea... --Dmb 16:59, 30 July 2008 (UTC)

This extension together with LDAPAuthentication extension
Using this extension together with the LDAPAuthentication extension is not optimal. We want to achieve ldapauthentication for users that have passed the ConfirmAccount steps ie been approved by the wiki sysop. So we have turned off the autocreation of users that tries to logon to the wiki and use their LDAP password, if they now use the Confirmaccount request form the username they fill in will be checked against the LDAP server and the message back is that the username already exists. That's true that it exist in LDAP but not in the wiki, this scenario is good but lacks one thing and that is that the request form can't be sent.

The check against LDAP is good, we now know that it's a real id on the account form, and now we need to be able to send the account request to the wiki sysop that will apply or reject the request. After an apply of the request the user can login with his username and ldap password.

there should be an check, if the username doesn't exist in the wiki database but exists in LDAP the request form should be sent. If the username doesn't exist in LDAP the request form should not be sent. And if the username exist in wiki database or in request queue, the request form should not be sent.

For the moment I just commented the code that made the check if user exist in LDAP and it works as I want, but I loose the possibility to just allow LDAP users to make requests. Any comments/advise on this ?

regards Hex
 * I can make a configuration variable for this. However, it will need to check that the local and global (ldap) accounts have the same password. Aaron 15:28, 23 August 2008 (UTC)


 * I do not see why the account password in the wiki must match the ldap password.

After the account is created, the user will logon with his ldap userid (which will be the same as is wiki id) and the password will be authenticated against the ldap server.

The user will not receive the created wiki password in the confirmation mail, so he/she will be unaware of it or at least not know it.

The local password will not be used at logon. Only ldap authentication is allowed.

We don't have access to add a LDAp id, just userid/password validation.

The matrix of how we wanted to have the account creation in wiki when using LDAPAutentication and ConfirmAccount together. WIKIid        LDAPid           Result account creation

No            NO               Deny creation of account in wiki  (request form will say nothing for the moment)

NO            YES              Allow creation of account in wiki

Yes           NO               Dup id in wiki deny creation in wiki (request form will say userexists)

YES           YES              DUP id in wiki deny creation in wiki (request form will say userexists) I have now altered the code in RequestAccount_body.php like this around line 261

This let the user submit the reuquest form without getting the message that the account exists (in LDAP)

He will unfortunatly not get a message that the account doesn't exist in LDAP if it's really doesn't exist in LDAP, but the form can't be submitted.

if( 0 != $u->idForName ) { $this->showForm( wfMsgHtml('userexists') ); return; }	       if( !$wgAuth->userExists( $u->getName ) ) { return; } Also needed to change ConfirmAccount_body.php around line 432 This let the sysop to confirm the request and get the wiki account created, the same goes here about the message to the sysop if the ldap account really doesn't exist (should only happend if ldap account is deletet since the request was done).
 * 1) Check if already in use disabled code by hex new code below
 * 2) 	if( 0 != $u->idForName || $wgAuth->userExists( $u->getName ) ) {
 * 3) 		$this->showForm( wfMsgHtml('userexists') );
 * 4) 		return;
 * }
 * 1) new code by hex

# Check if already in use disabled code by hex new code below #	if( 0! = $user->idForName || $wgAuth->userExists( $user->getName ) ) { #		$this->showForm( wfMsgHtml('userexists') ); #		return; #	}		   # new code by hex if( 0 != $user->idForName ) { $this->showForm( wfMsgHtml('userexists') ); return; }	   if( !$wgAuth->userExists( $user->getName ) ) { return; } I must also say thank You for this extension

/hex
 * If you don't check the passwords, then any person can create an account in the name of an LDAP users and then be treated as that user. Aaron 22:32, 28 August 2008 (UTC)
 * We do validation against LDAP, so if someone creates an account request of another id and that reguest is approved and the user has confirmed the email address, then when logging on with the ldap id you must know the password of the ldap id, not the local password (never used and is never mailed out to user, ie local password id unknown to all)

Invalid confirmation code. The code may have expired.
I'm testing ConfirmAccount on my local wiki prior to deploying it to my site. When my test user clicks the link in the e-mail, a page opens with the message:

“Invalid confirmation code. The code may have expired.”

My test site was using 1.11 and my main site is using 1.13, I just tried upgrading the test site in case that might be the problem. I'm still getting this error message.

What am I overlooking? --RKH 14:45, 26 September 2008 (UTC)

Resolution
I discovered the solution. I didn't have timezone set in PHP so when submitting the account request, MediaWiki displayed an error message box in red, noting that timezone wasn't set. Apparently that also caused problems with the ConfirmAccount confirmation code. When I set the timezone in PHP.ini, ConfirmAccount worked correctly.

Conclusion: You MUST set a valid timezone in order for ConfirmAccount to work correctly. --RKH 16:50, 26 September 2008 (UTC)

Error in code?
Hi. when i want to confirm a new user, th efollowing error massage occurs: Fatal error: Call to undefined method User::addNewUserLogEntry in /Users/patrick/Sites/mediawiki/extensions/ConfirmAccount/ConfirmAccount_body.php on line 561 how to fix? (by the way, i use MediaWiki 1.13.1 and the German localization)--89.196.67.174 05:56, 30 September 2008 (UTC).


 * You've already stated your problem...incompatible versions of extensions and MediaWiki software. You're attempting to use trunk (bleeding-edge) version of ConfirmAccount with an older, non-trunk version of MediaWiki software. You'll either have to use the branched version of ConfirmAccount extension or upgrade your wiki to trunk (see download from SVN for info on how to do that if you decide so...also be aware that trunk might even be broken at times). -- Sayuri 07:56, 30 September 2008 (UTC)


 * I'm also receiving this error with MediaWiki 1.13.2

Resolution
Without having this tried myself I'd say you need to edit "ConfirmAccount.i18n.php" and look for the entry "requestaccount-submit" in the $messages Array. Replace the text after the "==>" with what you desire.

--GangMan 07:56, 21 October 2008 (UTC)

Desired Additional Options
Aaron thanks for developing the MediaWiki extension. We are looking at implementing your ConfirmAccount extension for the TNG Wiki and would like to see the following options added


 * to the Request Account
 * optionally make List of websites, if any (separate with newlines): a required input field that would be used instead of the bio for creating the User:userpage
 * make some of the Request Account messages variables to allow localization of the request (as mentioned in Localizing account creation look and feel above)


 * to the create User:userpage
 * optionally add the Real Name as the first field in the User:userpage
 * optionally add a message line from a variable, such as My Genealogy Web Sites
 * optionally add the web site URLs from the List of websites, if any (separate with newlines):

so the userpage would look something like the following User:Ken Roypage

While we might be able to hack your extension to accomplish this, we would prefer not to have to modify the code.

TIA, Ken Roy

Reject or hold reason not showing in queue
Were any of the Extension_talk:ConfirmAccount/archive_1 added? Specifically was #3 in their list, the reason for Reject or Hold added to the review queue?

If it has not, we would also like to see this feature added to the ConfirmAccount Extension, since we also think that is critical for the other Reviewers to know why a request was rejected when it is received again as a different username.

Thanks

Ken Roy
 * You have to click the "(Review)" link (after the dates) to see it. Aaron 13:06, 9 October 2008 (UTC)


 * Thanks, I initially did not see the information, since I was looking in the comment box. Information shows as Rationale given to applicant: Thanks for the quick response. Ken Roy

No Special Page Exists error
I have followed all of the instructions to install this extension, but when I navigate to the special pages, I receive an error that says that none of the pages exist. What am I doing wrong? 99.141.103.173 22:48, 27 October 2008 (UTC)

Account Confirmation gets stuck after accepting.
Hi everyone,

I was just wondering, I installed this extension and everything seems to be working the way described.

I do have an issue when accepting new users. I open the https://mywiki/wiki/upgrade/index.php/Special:ConfirmAccounts and go to confirm the new account requests. It takes me to the user request, where I hit the confirm button at the bottom. Then it take me to https://mywiki/wiki/upgrade/index.php/Special:ConfirmAccounts/authors where nothing, it's a blank page. The user gets the confirmation email with the Password. After exiting the page, the request I just accepted is still in the queue. Is there something I'm doing wrong?

Thanks for help!
 * Probably an issue with https. Voice of All 18:45, 13 November 2008 (UTC)

Ok, I removed Require SSL and the ReWrite Rule, now it's just http. Same issue exists.

Thanks for the suggestion, anything else it could be?

I'm able to reject and hold, the only part not working properly is the confirm.

Here is more information about my install:
 * Product 	Version:
 * MediaWiki 	1.13.2
 * PHP 	5.1.6 (apache2handler)
 * MySQL 	5.0.45
 * Installed extensions:
 * Confirm user accounts (Version 1.46) 	Gives bureaucrats the ability to confirm account requests 	Aaron Schulz
 * wikicalendar 		Christof Damian
 * Add 'error_reporting( E_ALL | E_STRICT );' to localsettings.php Voice of All 07:16, 22 November 2008 (UTC)

Error in trying to use reCaptcha with ConfirmAccount
Hi Aaron,

Thank you for developing the ConfirmAccount extention. It appears it will meet our TNG Wiki needs. However, when I attempted to install the reCaptcha extension, it only appears to work when in Edit, but not for the ConfirmAccount, which returns a fatal error. When the debug variable is included, the traceback returned is shown in the problem I reported on the Support Desk.

Any clue as to where I need to look in order to resolve this issue will be greatly appreciated.

TIA, --Ken Roy 03:22, 27 November 2008 (UTC)
 * Use the current version of ConfirmEdit, not the one bundled with reCaptcha. Voice of All 06:59, 27 November 2008 (UTC)
 * Aaron, Thank you so much for your response, which did in fact resolve my problem. --Ken Roy 15:27, 27 November 2008 (UTC)

"log in / create account" link in Personal navbar missing
After installing ConfirmAccount plugin the link in the personal navbar (top right hand corner of page) changes from "log in / create account" to "log in". Any idea how to change this back, so that it is easy for users to see how to register? I tried editing in Special:Allmessages but to no effect. Many thanks for such a great plugin! Tommcd 11:21, 12 December 2008 (UTC)
 * Edit MediaWiki:Nav-login-createaccount. —Emufarmers(T 11:45, 12 December 2008 (UTC)

Feature request: make requestaccount-urls part optional
We like to support providing some confidential information in a request, but find a separate field for urls distracting and adding to barriers to participation. We currently change the requestaccount-urls legend text to tell users to ignore the next field, but we would prefer to be able to hide the field altogether. Can an additional "if( $wgAccountRequestExtraURLs )" be added to the code? We track mediawiki through subversion, so manual code modification is not desirable. Many thanks! --G.Hagedorn 15:17, 13 December 2008 (UTC)

Fatal Error after confirming
This extension works well; smoothly integrates with MW and does exactly what I need. Not sure if anyone else gets this error after approving a user's application, though -

Fatal error: Call to undefined method User::addNewUserLogEntry in (snip)\wiki\extensions\ConfirmAccount\ConfirmAccount_body.php on line 568.

The user is actually created, so I can keep working but obviously it looks horrible to see a fatal error. I'm running MediaWiki 1.13.3 with PHP 5.2.0 on Windows (yeah, the email setup was a PITA), plus Confirm User Accounts 1.46. Line 568 looks like a standard MW function: $user->addNewUserLogEntry;. Advice? -- Gth-au 03:15, 24 December 2008 (UTC)

I get exactly the same Error on fresh installed Wiki. MediaWiki 	1.13.3 PHP 	5.2.4-2ubuntu5.4 (apache2handler) MySQL 	5.0.51a-3ubuntu5.4

Same error here, MediaWiki 1.13.3
 * Either upgrade to 1.14 use use the 1.13 branch version of the extension. Voice of All 04:19, 15 January 2009 (UTC)

Don't understand MySQL step. Help please?
I'm quite lost at this part of the instructions:


 * Run the SQL query, substituting in your wiki's table prefix. ConfirmAccount.pg.sql is for PostgreSQL, and ConfirmAccount.sql is for MySQL. That is, find whichever of those two files, and send a query that creates the account_credentials and account_requests tables, with /*$wgDBprefix*/ replaced according to whatever is appropriate.

How do I "run the SQL query"? Do I just type "ConfirmAccount.SQL" at a command prompt? If it's something I have to do inside MySQL, I'm completely unfamiliar with how to use it. Is there somewhere I can look up exactly which commands to enter?

Thanks in advance for any help you can give me! --Quixote7 04:00, 24 December 2008 (UTC)

Also, when it says "replace /*$wgDBprefix*/ with whatever is appropriate" could you give an example? I have no idea what is meant. My database for my wiki on my server? "SQL" to stand for MySQL as opposed to Postgres? Some other database entirely? --Quixote7 04:14, 24 December 2008 (UTC)


 * Files ending in .SQL can usually be executed with an SQL database engine directly - refer to the MySQL documentation for the exact command-line syntax. As an alternative, if you have PhpMyAdmin you can highlight your database and select Query Window to paste the contents of the .SQL via a web browser.  Just remember that inside the ConfrmAccount.SQL file, you will need to make two smalls edits: you need to update the lines CREATE TABLE /*$wgDBprefix*/account_requests ( and CREATE TABLE /*$wgDBprefix*/account_credentials ( to match your installation's table-prefix.  If you're still lost as to what the prefix should be, open LocalSettings.php file and search for $wgDBprefix - this prefix value is what the ConfirmAccount SQL code needs to match. -- Gth-au 11:38, 24 December 2008 (UTC)


 * As you request an example of these edits, if your $wgDBprefix value was "mywiki_" then the two lines would be:
 * CREATE TABLE mywiki_account_requests (
 * and then further down, the second change would appear as:
 * CREATE TABLE mywiki_account_credentials (
 * Enjoy. -- Gth-au 11:41, 24 December 2008 (UTC)

That's much clearer. Thanks! Anything to do with MySQL is pretty much of a nightmare, as far as I'm concerned. In the ideal world, there'd be a front-end script that could just do all this :-) . I'll look for a Request For Features page for ConfirmAccount. --Quixote7 19:23, 24 December 2008 (UTC)

Bug with SharedDB
It don't works with $wgSharedDB, tries to access using the local prefix.Eloy 16:57, 31 December 2008 (UTC) Eloy 17:04, 31 December 2008 (UTC)
 * Ok, I fix it. I forget add the tables in LocalSettings:

Undefined method?
In trying to get ConfirmAccount to work, I get this error message when I try to approve a user:

Call to undefined method User::addNewUserLogEntry in /home/cpsquare/public_html/wiki/extensions/ConfirmAccount/ConfirmAccount_body.php on line 568

I'm also seeing problems re the simple Captcha, where it rejects correct information (I'm sure that I'm adding correctly). --Smithjd 01:24, 13 January 2009 (UTC)


 * r40769 broke compatibility with 1.13; use the 1.13.3 version instead. —Emufarmers(T 02:26, 13 January 2009 (UTC)


 * That fixes it -- for Firefox only. (It does just what I need!) However, the same account request input that works with Firefox, when submitted with Internet Explorer results in "Incorrect or missing confirmation code." (I'd use Firefox to approve requests, but need to have IE users able to request an account!) --Smithjd 17:52, 14 January 2009 (UTC)

Must be logged in to request an account
Trying to explain different behavior of CoonfirmAccount on different machines. Ruling out browsers, OS, etc. Surprise! I do not get the dreaded "Incorrect or missing confirmation code" message when I'm logged in creating an account for someone else, but I do get it when I'm not logged on. Does that signal an incorrect parameter I've set? Surely it's not designed to work that way. --Smithjd 17:40, 19 January 2009 (UTC)
 * ConfirmEdit is on I assume? Aaron 19:10, 19 January 2009 (UTC)
 * ConfirmEdit is "on" if this one statement in LocalSettings.php turns it on: --Smithjd 22:37, 20 January 2009 (UTC)
 * And r45908 has the same issue? Aaron 22:47, 20 January 2009 (UTC)
 * Yes it does --Smithjd 23:26, 20 January 2009 (UTC)
 * ConfirmEdit requires cookies by default. It may fail for some anons. You can try  to work around it. Aaron 01:17, 21 January 2009 (UTC)
 * That doesn't seem to make a difference.--Smithjd 05:45, 21 January 2009 (UTC)
 * And you added it *after* '"$IP/extensions/ConfirmEdit/ConfirmEdit.php"'? If it still fails, I'd just disable ConfirmEdit, not really needed on large sites. Aaron 06:34, 21 January 2009 (UTC)