Extension talk:ConfirmAccount

Jump to: navigation, search

About this board


By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

ConfirmAccount not compatible with ConfirmEdit right now?

4
183.83.51.83 (talkcontribs)

I'm new to MediaWiki so maybe I'm missing something obvious - I just installed 1.26.2 with latest plugins for ConfirmEdit and ConfirmAccount and the "Request Account" page for ConfirmAccount started failing as soon as I setup ConfirmEdit with RecaptchaNoCaptcha following exact instructions for both extensions. This was the error message I got the on clicking "Request Account":

Catchable fatal error: Argument 1 passed to ReCaptchaNoCaptcha::getForm() must be an instance of OutputPage, none given, called in /home/<mydomain>/public_html/wiki/extensions/ConfirmAccount/frontend/specialpages/actions/RequestAccount_body.php on line 231 and defined in /home/<mydomain>/public_html/wiki/extensions/ConfirmEdit/ReCaptchaNoCaptcha/ReCaptchaNoCaptcha.class.php on line 8

I managed to fix it by changing this line in RequestAccount_body.php

$form .= $captcha->getForm();

to

$form .= $captcha->getForm($this->getOutput());

This works, but I have absolutely no idea what I'm doing here frankly - I just made the parameters match by checking both files. Is this a known bug?

My thanks to all contributors for creating such a great piece of software in mediawiki and all these great extensions too!

58.233.10.17 (talkcontribs)

I have the same problem, and your quick fix seems to work for me. Thanks a lot for the suggestion. I hope that this problem is resolved sooner or later because I'm quite dependent on this extension.

87.123.33.215 (talkcontribs)

Please open a bugreport to get the fix integrated into the extension!

84.221.237.67 (talkcontribs)

Same error and same working solution.

Hope it will be fixed someday :-)

Reply to "ConfirmAccount not compatible with ConfirmEdit right now?"

If i try to request account the page works only for sysop

3
188.175.39.148 (talkcontribs)

I just set up everything.. i love the concept.. but i have one big problem..

my settigs:

read only for users, createaccount only sysop..

so that means to read my wiki you have to request account and be checked by admin..

but if i go to the special page.. it just shows the browser 500 error, even if i tried it on USER account.. only way i can see the page is to open it as sysop.. with a little warning that i am already logged in.. but i want to everyone be able to request account.. can u please help me?

here is link if it helps:

http://wiki.organizaceakci.cz/index.php?title=Speci%C3%A1ln%C3%AD:RequestAccount

Thanks, Jacob B.

Music1201 (talkcontribs)

Try adding this line to local settings:

$wgWhitelistRead = array( 'Special:RequestAccount', 'Main Page' );

188.175.39.148 (talkcontribs)

i tried it.. if i dont use it.. it says i dont have rights..

Reply to "If i try to request account the page works only for sysop"
Kersare (talkcontribs)

I have two wikis that both use ConfirmAccount. Due to the php version on the latest one, I had to go back to MediaWiki 1.19.24.

Basically I want this RequestAccount page: http://legacyfleet.net/wiki/index.php?title=Special:RequestAccount

to look like this one: http://wiki.horizonfleet.net/index.php?title=Special:RequestAccount

I seem to recall being able to edit what's shown on the RequestAccount page, but it's been a few years since I've done so and I no longer remember where to do it. I tried editing my LocalSettings.php, but even when I set some of the values to false (RealName, AreasofInterest, CV, Links, TermsOfService), they still show up on the RequestAccount page.

Can someone please clarify how I can get the first page I linked to look like the second one (not the colors and such, just the information that's shown/requested).

Thanks!

Rob Kam (talkcontribs)

Should be explained at Extension:ConfirmAccount

Kersare (talkcontribs)

If it was that easy, I wouldn't have asked here. ;)

I looked there already and it said to update LocalSettings. I did that, but it didn't change anything as I already said.

There must be something else to it or somewhere else that I need to edit what will show up on the Special:RequestAccount page so that the first link I gave will match the second the one as far as content.

Rob Kam (talkcontribs)

That was the wrong link. Look under the Minimal settings heading.

Kersare (talkcontribs)

I did that. It didn't change what was shown. That's what I said in my initial & first reply.

Kersare (talkcontribs)

Can anyone else help? I modified the LocalSettings.php so that the items I don't want shown are false, but they still show up on my wiki. I really want the first link's RequestAccount to look the same as the second one from my op.

Thanks?

Reply to "Customizing RequestAccount page"
188.32.111.14 (talkcontribs)

$wgGroupPermissions['sysop']['createaccount'] = false; --> $wgGroupPermissions['*']['createaccount'] = false;

Reply to "Error"

Email notification_Wiki{Pedia,Media,Gid,..,..,...}_DViach090877v{ru.Wiki(Pedia,Media,Versitet,..,..,...)}.html{Users_User.u}DeViaBr62

3
Noboddy (talkcontribs)

I don't get an email to the one specified in $wgConfirmAccountContact. Is there anything else I need to set up for this? Generally sending mails with php works for the rest of my Mediawiki installation.

Here is my configuration:

require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php";
$wgWhitelistRead = array( 'Spezial:Benutzerkonto_beantragen', 'Hauptseite' );

$wgConfirmAccountSaveInfo = true;
$wgConfirmAccountContact = 'my@email.address';
$wgAutoWelcomeNewUsers = true;
$wgGroupPermissions['bureaucrat']['lookupcredentials'] = true;
$wgGroupPermissions['sysop']['lookupcredentials'] = true;
$wgGroupPermissions['sysop']['confirmaccount'] = true;
$wgConfirmAccountRequestFormItems = array(
# Let users make names other than their "real name"
'UserName' => array( 'enabled' => true ),
# Real name of user
'RealName' => array( 'enabled' => true ),
# Biographical info
'Biography' => array( 'enabled' => false, 'minWords' => 50 ),
# Interest checkboxes (defined in MediaWiki:requestaccount-areas)
'AreasOfInterest' => array( 'enabled' => false ),
# CV/resume attachment option
'CV' => array( 'enabled' => false ),
# Additional non-public info for reviewer
'Notes' => array( 'enabled' => true ),
# Option to place web URLs that establish the user
'Links' => array( 'enabled' => false ),
# Terms of Service checkbox
'TermsOfService' => array( 'enabled' => false ),
);
Aaron Schulz (talkcontribs)

Did you wait till the user confirmed their email? Also there was a change in core that broke the extension in terms of sending certain emails. This was fixed in the "master" branches, but some older extensions versions might not work with newer core versions.

Noboddy (talkcontribs)

Thanks for your reply. I guess that was the problem, now I updated and once I click the confirm link it works. Thank you!

Reply to "Email notification_Wiki{Pedia,Media,Gid,..,..,...}_DViach090877v{ru.Wiki(Pedia,Media,Versitet,..,..,...)}.html{Users_User.u}DeViaBr62"

Installation works - but ext not showing

1
Stillhouse (talkcontribs)

I have followed all the installation instructions, and everything appeared to run smoothly:

  • Download and place the file(s) in a directory called ConfirmAccount in your extensions/ folder. - DONE
  • Add the following code at the bottom of your LocalSettings.php: - DONE
require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php"; 
  • Run the update script which will automatically create the necessary database tables that this extension needs. - DONE
  • Ensure the wiki has write permissions on $wgUploadDirectory, or manually set $wgFileStore['accountreqs'] and$wgFileStore['accountcreds'] to a writable directory of your choice. - DONE
  • Done - Navigate to Special:Version on your wiki to verify that the extension is successfully installed. - EXTENSION NOT SHOWN

Does anyone have any ideas of what could be wrong here? Much appreciated.

Reply to "Installation works - but ext not showing"
Andreas Plank (talkcontribs)

Hi,

I'm running a 1.27.0-wmf.9 and Extension:ConfirmAccount origin/master from 2915-12-14 – I know it is a development wiki state that I try to run – but after creating an account I could not log in, it issued the message: «Das Passwort ist falsch. Bitte versuche es erneut.» (Password incorrect. Please try again). The password I used was that from e-mail. I only could log in after proceeding to Special:ResetPassword. Have I missed some LocalSettings to take care of? Note that on this Wiki setup I had to reset the new password saving method pbkdf2 because there are older Wikis that share the user table:

$wgPasswordDefault ='B'; /* old MD5 hashing on shared Wikifamily with pre MW1.24 and post MW 1.24+ Wikis */

But normally this changed setting should not disrupt the request account process, right?

Any hint or solution to get it working properly at the very first log in? Regards Andreas

Andreas Plank (talkcontribs)

After

  1. confirming the new user
  2. confirming e-Mail address
  3. checking the database table user where the new user name will be inserted by the confirm process of new users
SELECT `user_id` , `user_name` , UNHEX( HEX( `user_password` ) ) AS 'user_password' FROM `user` ORDER BY `user_id` DESC

… I see that there is no password set whatsoever when the new user is created.

A bug?

Andreas Plank (talkcontribs)

The cause is in the MW 1.27 core, extension:ConfirmAccount calls User::createNew …

foreach ( array( 'password', 'newpassword', 'newpass_time', 'password_expires' ) as $field ) {
  if ( isset( $params[$field] ) ) {
    wfDeprecated( __METHOD__ . " with param '$field'", '1.27' );
    unset( $params[$field] );
  }
}

… but all of those data values (password, newpassword etc.) are deleted in the process and hence no password comes into the database at the first place that the login can compare with. So I guess there is some other concept of creating a new user from the MW-core point of view that extension:ConfirmAccount is not synchronous with?

Is there any solution to this in planning?

Reply to "Unkown password after account creation"

Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/wi/wik".

20
Daniel K. Schneider (talkcontribs)

MediaWiki 1.25beta (696dc35) Extension: code from GIT (both master and REL_25)

Hello,

  • I ran into this problem: Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/wi/wik"
  • Several persons reported this in older archieved messages, but my file permission are ok (i.e I can upload an image)
  • $wgFileStore to manually specify a directory will not work (has been removed since MW 1_24

Workaround (I find this truly freaky since the version appear to be the same, according to the "version" page in the wiki):

git checkout REL1_24

- cheers ! Daniel

Lajosb (talkcontribs)

I had this exact same problem, and your trick worked for me too.

But why?...

Nemo bis (talkcontribs)

It means the lastest code of the extension is not compatible with your MediaWiki.

Lajosb (talkcontribs)

Yes, of course that's what it means, but that's really very odd. Like Daniel, I'm using WM 1.25 and the extension version for WM 1.25 (i.e. the version intended for that MW version) isn't working, while an older version (namely that for MW 1.24) is. In other words, the "right" version doesn't work, while a "wrong" version does.

(By the way, I had this problem also with the WikiForum extension. In that case too the 1.25 version had a problem that was solved by downgrading to the 1.24 version.)

Nemo bis (talkcontribs)

There is no guarantee that extensions work with any version. The branches are just a time approximation.

Bawolff (talkcontribs)

Usually that type of error is caused by a permission issue. The extension defaults to $wgUploadDirectory . "/accountcreds" as the directory to use. Make sure that php can create that directory and any subdirectories (e.g. Let the php user [usually www-data] own that directory).

Well $wgFileSotre was removed, you can still set it in LocalSettings.php. The more proper way would be to adjust $wgConfirmAccountFSRepos

Wess (talkcontribs)

Facing the same problem too, downgrading the syst. I could not understand the solution described above. As I understand it tries to save those files at the server root directory. Right now my workaround was to comment out all the file saving issues...

In addition - right now the e-mails to the admin are sent only after email address confirmation. Is there's any possibility to send them at the time of registration?

38.89.3.44 (talkcontribs)
80.252.174.242 (talkcontribs)

Any solution to this? I don't get the comment "git checkout REL1_24"

117.203.118.130 (talkcontribs)

Hello. I am facing the same problem. This discussion does not make clear about how to resolve it. Please guide in a step by step manner.

Jschrempp (talkcontribs)

I have the same problem. I just applied the 1.24.3 patch to 1.24.2. The ConfirmAccount extension was working with 1.24.2.

193.33.2.101 (talkcontribs)

Do you have $wgUploadDirectory = true; in Local Settings?

Wmat (talkcontribs)

This is still a problem with MW 1.25.1 and REL1_25 of the extension.

Ken Roy (talkcontribs)

Download and install the ConfirmAccount extensions for MW 1.24.

I had to do a similar backlevel for the CategoryTree extension where I needed the MW 1.23 version for it to work with MW 1.25.3

Eburcat (talkcontribs)

With MW 1.26 this has become a real issue for us. Can't checkout REL1_25 or REL1_24 - it crashes the whole site, and can't confirm any new accounts now...

Edit: solved it by replacing in the file ConfirmAccount.config.php, this line:

$wgFileStore['accountcreds']['directory'] : $wgUploadDirectory . "/accountcreds",

with the line:

$wgFileStore['accountcreds']['directory'] : "{$IP}/images/accountcreds",

212.122.223.98 (talkcontribs)

Thats great... thanks a lot :)

Dvlink (talkcontribs)

Thank you Eburcat!!

Paladox (talkcontribs)

Patch uploaded at https://gerrit.wikimedia.org/r/#/c/258373/ for mediawiki 1.27 alpha.

74.76.112.55 (talkcontribs)

Patch worked for me... I manually made the edits found in the above link by looking at the diff. So far so good.

Paladox (talkcontribs)

Ok. Please try the new patch I just uploaded at https://gerrit.wikimedia.org/r/#/c/258373/ please.

Reply to "Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/wi/wik"."

Error running updater.php with Postgres backend

1
174.71.94.45 (talkcontribs)

I'm reporting a bug here that I encountered while using ConfirmAccount with the Postgres backend. Running the updater fails with this error:

Adding column 'account_requests.acr_agent'
A database query error has occurred.
Query: ALTER TABLE account_requests ADD acr_agent /snip/mediawiki/extensions/ConfirmAccount/backend/schema/postgres/patch-acr_agent.sql
Function: DatabaseBase::query
Error: 42601 ERROR:  syntax error at or near "/"
LINE 1: ...e::query  */ TABLE account_requests ADD acr_agent /snip...
                                                             ^

Reason: the third parameter to addPgField should be the type, not a patch file. Since the patch file in this case is very simple, it can be replaced with a series of addPgField calls. Otherwise, it would have to be applied with a different function (addTable, maybe, though that's not what's really happening).

Solution: Apply this patch to extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php:

diff --git a/extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php b/extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php
index 54e6d31..d07dc54 100755
--- a/extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php
+++ b/extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php
@@ -34,7 +34,10 @@ class ConfirmAccountUpdaterHooks {
                        $updater->addExtensionUpdate( array( 'addPgField', 'account_requests', 'acr_areas', "TEXT" ) );
                        $updater->addExtensionUpdate( array( 'addPgField', 'account_credentials', 'acd_areas', "TEXT" ) );
                        $updater->addExtensionUpdate( array( 'addIndex', 'account_requests', 'acr_email', "$base/patch-email-index.sql", true ) );
-                       $updater->addExtensionUpdate( array( 'addPgField', 'account_requests', 'acr_agent', "$base/patch-acr_agent.sql", true ) );
+                       $updater->addExtensionUpdate( array( 'addPgField', 'account_requests', 'acr_xff', "TEXT" ) );
+                       $updater->addExtensionUpdate( array( 'addPgField', 'account_requests', 'acr_agent', "TEXT" ) );
+                       $updater->addExtensionUpdate( array( 'addPgField', 'account_credentials', 'acd_xff', "TEXT" ) );
+                       $updater->addExtensionUpdate( array( 'addPgField', 'account_credentials', 'acd_agent', "TEXT" ) );
                }
                return true;
        }
Reply to "Error running updater.php with Postgres backend"
WmBliss (talkcontribs)

After the new user confirms their email, ConfirmAccount seems to be sending 2 duplicate pending account notifications. This was reported in 2011, but that installer did not get any solution responses.

Any ideas what I set up incorrectly?

Wmat (talkcontribs)

I can confirm this is still a problem with MW 1.25.1 and ConfirmAccount REL1_24. Note, running REL1_24 due to the 'Could not create directory: wmstore...." error above.

I am receiving 3 notices of pending accounts.

Reply to "Duplicate Email Notifications"