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)