https://bugzilla.wikimedia.org/show_bug.cgi?id=65850
--- Comment #2 from Chris Steipp <cste...@wikimedia.org> ---
At an architectural level, there's a couple of things that concern me:
* It seems like a violation of least privilege / separation of duty that those
who can view results always get 100% of them, and have to do their own analysis
to figure out which petition was signed.
* If we get hit with "spam" (obviously not visible to the public, so low value
to the spamer.. but a user could easily write javascript to submit the form 10M
times), there's no way to delete it other than deleting rows in the DB. That
seems like it will come back to bite us.
* Similarly, if we notice abuse, the extension doesn't respect user blocks.
* The extension doesn't integrate with abusefilter / spam blacklist or
Checkuser. The spam ones, again, we probably don't need. If someone starts
submitting death threats in the petition comments, then we will want Checkuser
integration.
Some specific implementation things that should get fixed:
* Petition::petitionRender() - $htmlOut .= wfMessage('petition-num-signatures',
$numberOfSignatures)->text(); should be escaped or parsed. Since it's coming
from a count in the db, there's no xss in this code, but it's more likely to
prevent in the future if it does that now.
* Make sure when you export to csv, values starting with '=' should get escaped
(most spreadsheet applications will automatically interpret it as an equation
and run).
* Since you don't set any caching headers, by default the CSV shouldn't get
cached, but you may want to be explicit and say it shouldn't be cached.
* (performance) Trust Aaron's input over mine, but it seems like you would want
to count(pt_id) instead of count(*), so the count comes from index on innodb
tables.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
