UploadBase::performUpload() now takes a $tags parameter and passes it
to LocalFile::upload() and LocalFile::recordUpload2(), which
eventually adds the requested tags to the log_id, rev_id and rc_id
that are created for the file upload.
Previously you'd have to query the database for the latest rev_id and
log_id for the page title under which the title is being uploaded, as
performUpload() is unable to return them to you because it's all
deferred in funny ways.
Bug: T121874
Change-Id: I99a8fd67c84219d2715d3d88cc21500614431179
In HHVM, the settings 'upload_max_filesize' and 'post_max_size' are
not available via ini_get() due to some long-standing bug
(https://github.com/facebook/hhvm/issues/4993). Instead, one can use
'hhvm.server.upload.upload_max_file_size' and 'hhvm.server.max_post_size'
(in a typical PHP fashion, their names are subtly different than the
originals as to increase the potential for confusion).
Added a new method UploadBase::getMaxPhpUploadSize() to handle this.
Additionally:
* 'post_max_size' can be set to 0, which is equivalent to no limit.
Handle this correctly.
* $wgMaxUploadSize can be an array structure, instead of just a number.
Handle this correctly by using UploadBase::getMaxUploadSize().
* When no maximum is set, use PHP_INT_MAX rather than 1e100. It should
be big enough, and the latter is a float, results in 0 when cast to
int, and doesn't look as pretty when formatted in GB in the interface.
Bug: T116347
Change-Id: Idf707253eeae1b90792a7e26d2ab66d1317e67ae
Also consistently use self:: instead of BagOStuff:: for constants
referenced within the BagOStuff class.
Change-Id: I20fde9fa5cddcc9e92fa6a02b05dc7effa846742
Remove empty line comments as found by the
MediaWiki.WhiteSpace.SpaceBeforeSingleLineComment.EmptyComment sniff
Change-Id: I5d694f7a7d3bc97e16300ba03c60ad17f3c912a5
The 'was-deleted' warning was generated by getExistsWarning(), which
was returning immediately if this was found to be the case. A bunch of
later checks were incorrectly skipped, in particular 'exists-normalized',
which was resulting in UploadWizard incorrectly ignoring that problem.
I'm not sure why that was part of getExistsWarning() at all, it
doesn't seem very relevant. For that matter, neither do the 'thumb',
'thumb-name' and 'bad-prefix' warnings that it also generates, but
this should not be a problem in practice and so I'm leaving them alone.
Other than by allowing some more warning types to appear together or
in different order, this should not affect action=upload API output or
Special:Upload (which was updated appropriately). It does affect
'action=query&prop=imageinfo' output's 'html' property (used for AJAX
checks on Special:Upload), which no longer includes the 'was-deleted'
warning; this was never specified anywhere and just a side-effect.
Bug: T48741
Change-Id: I3686ee8ffd635f5f06f51971b6f16e3e66f33a9e
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
This patch is to generate specific error (warning) message when
blocking an svg file.
The checkSvgScriptCallback function has been updated, and it's
return type is changed from boolean to array.
A new variable is added to XmlTypeCheck class that contains the
type of error when svg file is uploaded, which is used to generate
concrete error messages later on.
I have added concrete error messages to i18n/en.json and their description
to qqq.json file. Please review the error messages and their description.
Bug: T85924
Change-Id: I3f687bf5b86ce66b703591b85fd03f073aacff4f
Fix for iSEC-WMF1214-11 and issue reported by Cure 53, which got
around our blacklist on embedded href targets. Use a whitelist instead.
Bug: T85850
Change-Id: I17b7ed65935b818695a83fd901fcaf90fffecf28
@import in embedded CSS is case-insensitive, meaning
an attacker can put "@iMpOrT" and it should still
work.
This uses stripos instead of strpos to make the check
case insensitive.
Bug: T85349
Change-Id: I31db9d81f46460af2d8d3f161ba46c2ab7a170d1
* Callers that should not use caches won't
* Aliased the old "bypassCache" param to "latest"
bug: T89184
Change-Id: I9f79e5942ced4ae13ba4de0b4c62908cc746e777
- As of now, we detect duplicate files by a combination of sha1
and file extension.
- Since multiple file extensions for the same MIME are permitted
this method does not reliably work.
Bug: T74070
Change-Id: If13059441097799227f23ece36a96c8375f17aab
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
For non-vectorial content, requesting a thumbnail larger than
the original results in a 500. Prerendering in its current form
introduces an increase in 500s that dilutes the real problematic
500s, making troubleshooting harder than it needs to be.
Change-Id: I9418dee7653ad7954c3788ecdd350fc8772edd32
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/301
Chunked uploads of SVGs are currently failing with "invalid XML" errors
because UploadBase::detectScriptInSvg() requires the full file but is
being called from UploadBase::verifyPartialFile().
So let's do the check twice: once in UploadBase::verifyPartialFile()
where it will pass if non-well-formed, and once in
UploadBase::verifyFile() where it will fail if non-well-formed.
Bug: 65724
Change-Id: I6126e185eb4b183c31946f13c576521f1ed19c16
* This causes problems with some session handlers and it is
also trickier to deal with in non CLI script without leaking
cookie headers.
Change-Id: Iaf2a57f9299e42a5f68bf85115e62e88fa0f8ed6
- Added newline at end of file
- Removed double spaces/newlines
- Added space after if/function and parentheses/brackets
- Removed space before comma/cast
- Fixed indent of some lines
Change-Id: I29867ffdffdfb7d2b56997e9393497c7dc12f7d3
* Filter <style> elements
* Normalize style elements and attributes before filtering
* Add checks for attributes that contain css
* Add unit tests for html5sec and reported bugs
Bug:69008
Change-Id: I732eece710f1bfaaeea1e5de541fcd4cfb375de7
http://phpdoc.org/docs/latest/references/phpdoc/types.html
If IDEs have many warnings, we don't look at them.
Let's minimize the number of warnings, and make them useful again.
* Some function docs fixes
* Removed unused $iwprefixes var in ApiQuerySearch.php
* declared private $blockStatusByUid in SpecialActiveusers
* declared private $repo in UploadFromChunks
Change-Id: Ifd20f78b168b9a913fdb8d89dc26a76a173b1c29
Spotted on beta:
--------
commonswiki-375c0c3e:
0.0752 1.9M mime: <image/png> extension: <png>
--------
With lot of requests, that causes them to be interlayed and ungreppable.
Change-Id: Ib99bc9547bdecb9efa59b7d292ddd7d10a552652
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: Ie419638e909a47aa72a274043604247830ee1a81
json, csv, and tsv are often detected as text/plain. However that's
not right. This patch causes MediaWiki to look at the file extension
of files detected as text/plain, and if the file extension is
for a "textual" type, use the mime type associated with that extension.
This change also changes the "does mime type match uploaded file
extension" check to use the mime based on the file contents
plus extension, as opposed to just the file contents. Various
documentation suggests this is more appropriate (e.g. line 807
of MimeMagic.php). In my opinion we should use just the file
contents when verifying file is not on blacklist, but use ext
when verifying file type matches extension, and for decided
what handler specific checks to run. Not the detect mime type
with extension doesn't override the detected mime type with
the extension, but only uses the extension if content based
detection is ambigious or not specific enough.
This patch should be reviewed by csteipp before merge for
any potential security implications.
Note: This is partially fixing a regression from 3846d10487,
where previously csv and json files were allowed to be uploaded,
and that change prevented them
Bug: 66036
Bug: 45424
Change-Id: Ib637fe6850a81b26f84dc8c00ab4772f3d3a1f34
On bug 65724, it was discovered that a user could upload SVG images
with embedded <image> elements that pulled in the resource via http.
This could allow an attacker to track all viewers of an SVG by having
the image embed another image hosted on their own server.
While testing the patch, I also identified 3 more element namespaces
that have been used on commons and seem harmless, so I added those to
the whitelist.
Change-Id: Iaaabc3a60c0ec4e6e426a8680d7a2cef5d469d29
Noticed that we have several old images on commons that use these
namespaces. They seem harmless, so I think we should add them.
Change-Id: Ib80298256c5d4717867eb857d5404a9487fed784
