MWX/Invite/notes/take 2

From Woozle Writes Code
< MWX‎ | Invite‎ | notes(Redirected from Special-Invite/notes/take 2)
Jump to navigation Jump to search

What seems like it should work, but hasn't, is to intercept the userCan hook, ignore anything that isn't the SpecialCreateAccount, and authorize everything as long as a valid invite code is passed.

The problem is that authorizing access doesn't seem to authorize access; I still get this same message:

You do not have permission to do that, for the following reason:
You are not allowed to execute the action you have requested.

So now it's a matter of tracing back through the code to find out why it thinks this.

The second line corresponds to the error message badaccess-group0. I searched the code for that message and found several possible places where it could be occurring. The one which was actually being tripped was this:

Original exception: [e851e4d8ff408613bd96ef03] /w/Special:CreateAccount Exception from line 587 of /home/psycrit/site/mediawiki-1.34.2/includes/Permissions/PermissionManager.php: 2020-09-10 What is triggering this error? action=deletedhistory
Backtrace:

  • #0 /home/psycrit/site/mediawiki-1.34.2/includes/Permissions/PermissionManager.php(789): MediaWiki\Permissions\PermissionManager->missingPermissionError(string, boolean)
  • #1 /home/psycrit/site/mediawiki-1.34.2/includes/Permissions/PermissionManager.php(395): MediaWiki\Permissions\PermissionManager->checkQuickPermissions(string, User, array, string, boolean, Title)
  • #2 /home/psycrit/site/mediawiki-1.34.2/includes/Permissions/PermissionManager.php(229): MediaWiki\Permissions\PermissionManager->getPermissionErrorsInternal(string, User, Title, string, boolean)
  • #3 /home/psycrit/site/mediawiki-1.34.2/includes/Permissions/PermissionManager.php(248): MediaWiki\Permissions\PermissionManager->userCan(string, User, Title, string)
  • #4 /home/psycrit/site/mediawiki-1.34.2/includes/skins/Skin.php(733): MediaWiki\Permissions\PermissionManager->quickUserCan(string, User, Title)
  • #5 /home/psycrit/site/mediawiki-1.34.2/includes/skins/SkinTemplate.php(284): Skin->getUndeleteLink()
  • #6 /home/psycrit/site/mediawiki-1.34.2/includes/skins/SkinTemplate.php(215): SkinTemplate->prepareQuickTemplate()
  • #7 /home/psycrit/site/mediawiki-1.34.2/includes/OutputPage.php(2574): SkinTemplate->outputPage()
  • #8 /home/psycrit/site/mediawiki-1.34.2/includes/MediaWiki.php(537): OutputPage->output()
  • #9 /home/psycrit/site/mediawiki-1.34.2/index.php(44): MediaWiki->run()
  • #10 {main}

Unfortunately, this turns out not to be the place where the exception is actually being thrown. From what I can tell, the above is the result of a UI check in the SkinTemplate class to see if various action-links should be displayed. If they shouldn't, then it just doesn't display them; the decision not to display the CreateAccount form is taking place somewhere else.

I should probably look at the CreateAccount code...

(Note: I also took a look at the source code for Extension:InviteSignup, especially InviteSignupHooks.php, and copied some of its techniques -- but that doesn't seem to have fixed the problem.)

SOLUTION: It turns out the problem was simple – I had failed to declare some of my hooks in the extension.json file, so important code wasn't getting called. If I'd been less distracted, I might have noticed this sooner.

2nd Pass

The only tricky part now is how to let the CreateAccount page know, on the second time around (after the user submits their desired credentials), that the user still has permission to access the page.

One way would be to insert the invite code into the form data as a hidden field; it's not clear how to do this, however. It seems to involve the AuthManager class, and I haven't come across any example code. (The InviteSignup extension uses a deprecated method to insert fields into the form.)

The easy way seems to be to just pass it as a cookie, so that's what I'll do for now.