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)

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)

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