Wait a second. Concerning the password reset, currently it uses the
user_newpassword field, which means the user is required to reset their
password upon login. How is this any different than using a reset token,
where the user supplies the reset token and changes their password?
*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
| tylerromeo(a)gmail.com
On Fri, Aug 24, 2012 at 1:38 PM, Derric Atzrott <
datzrott(a)alizeepathology.com> wrote:
Meta
discussions over community, Appreciation threads, GSoC wrapups,
Deployment threads, and orthogonal questions.
Lately wikitech-l seems to be almost void of one of the most important
categories of discussion I like to see here.
Discussions on adding new features to MediaWiki!
So, just like Sumana's "Appreciation thread" how about a little thread
dedicated to listing out things we'd like to see in MediaWiki or perhaps
would like to write ourselves.
Not really big things like VisualEditor, Wikidata, and Lua who have teams
of people within WMF working on them. But rather those other important
things a lot of us may want but always end up pushed to the side and
forgotten.
For me...
...
- OAuth: Well not actually OAuth. After getting a full understanding of
this topic implementation of actual OAuth (1&2) looks like a dark
dead-end. Rather than OAuth I'd like to write a new auth standard that
learns from all the good things and the mistakes made in both versions of
OAuth and takes note of all the things we really need. And then implement
it into MediaWiki and write a series of server and client libraries/sdks
so it's also easier to pick up than either OAuth.
Obligitory XKCD:
http://xkcd.com/927/
...
Now some old and forgotten code topics:
...
- Password reset tokens: It's unbelievable but we are STILL using
temporary passwords instead of reset tokens. Naturally this is less usable
and also lowers the security of our password reset system.
I had no idea we were doing that. That /is/ really bad!
- An abstract revision system. The way we shove
configuration into i18n,
i18n into articles, scripts and stylesheets into articles, and extensions
go and do the same. All just to get proper revisioning of things. Is
horrible. Not to mention the extensions that don't and rely on our logging
system which makes it harder to revert things. With all this together I'd
like to see an abstract system that lets extensions have their own
revision system outside of page content for whatever they need to do.
This. I would pay you for this one. Not a living by any means, but I
would be
willing to put $20-$30 towards whoever implements that as a gift and a
"Thank
you". All my extensions at my job have to keep track of revisions and it
is a
pain to reimplement it every time. I still haven't gotten my history UIs
anywhere close to as nice as the one used by Mediawiki.
-------------
That all said, this a fantastic topic idea. I can't wait to see where this
goes.
Thank you,
Derric Atzrott
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l