On Nov 20, 2003, at 17:11, Evan Prodromou wrote:
So, I've been coming up with great ideas for MediaWiki -- or, rather, great ideas for enhancements for MediaWiki for Wikitravel's needs. But I figure it's probably going to be easiest to get into the code if I start working on some bugs instead.
Are there any bugs that an interested volunteer could start working on and submitting patches for? The huge list on sourceforge is a bit much.
Some things off the top of my head...
Login doesn't actually check that the session cookie is present, so someone coming in with cookies disabled is told their login is successful but it's lost when they visit the next page. We really should check for this condition! It's a fairly frequently reported problem, and probably not that hard to fix. In all probability, simply checking for the existence of the session cookie at the top of SpecialUserlogin.php and complaining if it's not there will be enough. (Bug #770011)
The "Cologne Blue" skin has a few minor problems where useful/important links are missing, and various stylistic issues. The structure of the current skin code is kind of difficult to grasp, but the individual bits are fairly not too insane, I think. (Bugs #825774, 827160, etc) See http://meta.wikipedia.org/wiki/Cologne_Blue_skin_problems
If you want an ugly but simple and important job... we'd like to remove our dependency on register_globals (the option, formerly on by default, in which GET/POST parameters and cookies are dumped into the global variable namespace). Since PHP 4.2 this option is off by default, as it can lead to security problems when there's sloppy coding and you use a variable that turns out to be uninitialized -- until someone slips it into a URL or cookie.
Moving from the globals to the $_GET and $_POST arrays would let us remove that configuration dependency and potentially clean up some security trouble if there are any more surprises. (Also related to bug #842921)
It's drudge work, but if you pick it up you'll get a quick overview of the whole codebase! :)
Another thing that would be nice would be proper locking and/or use of transactional BEGIN/COMMIT wrappers and handling of errors with rollbacks where multiple SQL statements are required to perform a read/write operation. We do have race conditions where simultaneous actions could perhaps interfere with each other, or where an operation that fails partway through leaves the database in an inconsistent state. Again, that's kind of drudge work, sorry. :)
See also here: http://meta.wikipedia.org/wiki/Development_tasks
-- brion vibber (brion @ pobox.com)
On Friday 21 November 2003 12:52, Brion Vibber wrote:
If you want an ugly but simple and important job... we'd like to remove our dependency on register_globals (the option, formerly on by default, in which GET/POST parameters and cookies are dumped into the global variable namespace). Since PHP 4.2 this option is off by default, as it can lead to security problems when there's sloppy coding and you use a variable that turns out to be uninitialized -- until someone slips it into a URL or cookie.
Moving from the globals to the $_GET and $_POST arrays would let us remove that configuration dependency and potentially clean up some security trouble if there are any more surprises. (Also related to bug #842921)
Perhaps there is something I don't see, but wouldn't it be the easiest to just insert before line 21 (global $action, $title...) in wiki.phtml:
$action=$_GET['action']; $title=$_GET['title']; $search=$_GET['search'], $go=$_GET['go']; $target=$_GET['target']; $printable=$_GET['printable']; $returnto=$_GET['returnto']; $diff=$_GET['diff']; $oldid=$_GET['oldid'];
Then, without any further changes to the source, register_globals could be turned off, there would be no configuration dependency, and no security risk (no new variables would be accepted). The same should be done for $_POST, of course.
On Sat, Nov 22, 2003 at 07:03:20AM +0100, Nikola Smolenski wrote:
On Friday 21 November 2003 12:52, Brion Vibber wrote:
If you want an ugly but simple and important job... we'd like to remove our dependency on register_globals (the option, formerly on by default, in which GET/POST parameters and cookies are dumped into the global variable namespace). Since PHP 4.2 this option is off by default, as it can lead to security problems when there's sloppy coding and you use a variable that turns out to be uninitialized -- until someone slips it into a URL or cookie.
Moving from the globals to the $_GET and $_POST arrays would let us remove that configuration dependency and potentially clean up some security trouble if there are any more surprises. (Also related to bug #842921)
Perhaps there is something I don't see, but wouldn't it be the easiest to just insert before line 21 (global $action, $title...) in wiki.phtml:
$action=$_GET['action']; $title=$_GET['title']; $search=$_GET['search'], $go=$_GET['go']; $target=$_GET['target']; $printable=$_GET['printable']; $returnto=$_GET['returnto']; $diff=$_GET['diff']; $oldid=$_GET['oldid'];
Then, without any further changes to the source, register_globals could be turned off, there would be no configuration dependency, and no security risk (no new variables would be accepted). The same should be done for $_POST, of course.
I tried that yesterday (using $_REQUEST, so I don't have to worry about GET/POST) and it's not that easy. There are many additional parameters passed from various dialogs. E.g. the code above is missing wpTextbox1, the big textbox you edit the wiki articles in.
I've already got 80% of code working, I think.
Regards,
JeLuF
"JF" == Jens Frank JeLuF@gmx.de writes:
JF> I tried that yesterday (using $_REQUEST, so I don't have to JF> worry about GET/POST) and it's not that easy. There are many JF> additional parameters passed from various dialogs. E.g. the JF> code above is missing wpTextbox1, the big textbox you edit the JF> wiki articles in.
JF> I've already got 80% of code working, I think.
Hey, so, I'm sure glad I didn't start working on this one.
~ESP
"BV" == Brion Vibber brion@pobox.com writes:
BV> Another thing that would be nice would be proper locking BV> and/or use of transactional BEGIN/COMMIT wrappers and handling BV> of errors with rollbacks where multiple SQL statements are BV> required to perform a read/write operation.
So, I've been looking this over, and I'm just realizing that it's over my head for now. I'm gonna have to defer on it, and try to patch some less ubiquitous bugs instead.
~ESP
wikitech-l@lists.wikimedia.org