Last modified: 2014-02-20 02:07:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17700, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15700 - Separate out and clean up account creation logic in MediaWiki core (tracking)
Separate out and clean up account creation logic in MediaWiki core (tracking)
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.21.x
All All
: Low enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: tracking
: 29785 (view as bug list)
Depends on: 17312
Blocks: code_quality tracking
  Show dependency treegraph
 
Reported: 2008-09-23 21:59 UTC by charitwo
Modified: 2014-02-20 02:07 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description charitwo 2008-09-23 21:59:00 UTC
Seems simple enough.

Special:Userlogin and Special:Createaccount
Comment 1 Raimond Spekking 2008-09-23 22:05:05 UTC
Why do you need separate special pages?
Comment 2 charitwo 2008-09-23 22:08:28 UTC
Why not? It makes sense, when you're making an account it's not technically logging in. I don't see why it shouldn't be a separate page considering it's using a separate form. Trivial change, perhaps. Practical change? Definitely.
Comment 3 Chad H. 2008-09-24 12:05:27 UTC
Historically, they were on the same page. Now that the logic abstracted them to separate "pages" (one specialpage, two different forms), it should be fairly trivial to move them entirely apart. I'd still keep Special:Userlogin?type=createaccount as a redirect for Special:CreateAccount, for b/c, but other than that I can't see a reason to keep them together anymore.

Special:UserLogout is separate :)
Comment 4 Alexandre Emsenhuber [IAlex] 2011-07-09 09:12:23 UTC
*** Bug 29785 has been marked as a duplicate of this bug. ***
Comment 5 spage 2012-12-08 02:45:36 UTC
FWIW, Extension:SignupApi makes a change to add Special:UserSignup and that part seemed to work, although I didn't try it with all variations like $wgUseCombinedLoginLink. This might be an easy change, but verifying it everywhere is the challenge.
Comment 6 Nemo 2013-02-03 23:52:46 UTC
special:createaccount has existed for ages. Yes, it's only an alias; but now it also has separate incoming links in the UI.
Comment 7 MZMcBride 2013-02-04 06:11:10 UTC
Re-opening for now. I believe the request here is for "Special:UserLogin/signup" to become (redirect to) "Special:CreateAccount". Currently the redirect goes the other way. That's how I read comment 0 and comment 3, at least.
Comment 8 Nemo 2013-02-04 07:28:29 UTC
It would be confusing. It will be a different special page when the logic is actually separate.
Comment 9 charitwo 2013-02-04 07:29:29 UTC
Just because you think it's confusing doesn't make it not worthwhile.
Comment 10 Nemo 2013-02-04 07:38:00 UTC
(In reply to comment #9)
> Just because you think it's confusing doesn't make it not worthwhile.

Sigh.
Comment 11 spage 2013-02-05 20:03:05 UTC
URLs are important. It's needlessly confusing that creating an account puts users on a page Special:UserLogin&type=signup , regardless of the code internals.

A comment from the redirecting function SpecialCreateAccount() in SpecialPage.php :
 * @todo FIXME: This (and the rest of the login frontend) needs to die a horrible painful death
Comment 12 Nemo 2013-02-05 20:19:46 UTC
(In reply to comment #11)
> A comment from the redirecting function SpecialCreateAccount() in
> SpecialPage.php :
>  * @todo FIXME: This (and the rest of the login frontend) needs to die a
> horrible painful death

Yes. But that's bug 17312.
Comment 13 MZMcBride 2013-02-05 21:04:08 UTC
(Copying comment from bug 17312 comment 0)
At the moment, UserLogin is concentrating too much responsability:
1. Displays and manage a form intended for gathering login information;
2. Displays and manage a form intended for gathering information for a new
account (create new account link)
3. Manages part of authentication process;
4. Coordinates creation of a new account.

From the 'object orientation' point of view, clearly UserLogin should be split
on smaller components.
UserLogin, IMHO, should be *only* reponsible for
    1. Displays and manage a form intended for gathering login information;

Other tasks should be managed by their corresponding responsible classes.
In fact, it does not matter whether Mediawiki is object oriented or not. Object
orientation is a very useful (and helpful!) concept which can be implemented
even in bash scripts. Object orientation (or at least the concept) allows
better organization of code, it's easy to maintain, easier to extend and easier
to adjust to specific needs.

I've integrated LDAP authentication in our wiki and it was a nightmare :(
Now I'd like to replace LDAP by SAML and it's another nightmare, not working
yet :(

Separating concerns on different classes would allow easier integration with
several authentication layers.
* One thing is getting username/password/domain from a form.
* Another thing is using username/passoword for authenticating against a
certain authentication layer.
* Another thing is obtaining data required for registration and coordinating
the registration workflow.
* Another thing is performing the steps required to create a new account in a
certain respository.

A good example which shows how integration is tangled can be seem at:
https://ow.feide.no/simplesamlphp:mediawiki
and the corresponding 'plugin' provided by:
https://ow.feide.no/_media/simplesamlphp:simplesamlphp-mw.php.zip?id=simplesamlphp%3Amediawiki&cache=cache

Thanks very much

Richard Gomes
http://www.jquantlib.org/index.php/User:RichardGomes
Comment 14 MZMcBride 2013-02-05 21:04:51 UTC
*** Bug 17312 has been marked as a duplicate of this bug. ***
Comment 15 MZMcBride 2013-02-05 21:07:28 UTC
(In reply to comment #12)
> Yes. But that's bug 17312.

FTFY.
Comment 16 Nemo 2013-02-05 21:28:16 UTC
(In reply to comment #15)
> (In reply to comment #12)
> > Yes. But that's bug 17312.
> 
> FTFY.

The summary you chose for this bug is surely incorrect if you mean it to be a duplicate of bug 17312; I'm not a coder, though, so I leave this to those who understand the logic here.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links