| Age | Commit message (Collapse) | Author |
|---|
|
Previous two commits in this topic branch introduced substantial
changes.
|
|
Don't repeat yourself with multiple POMF_FILES_ROOT.$newname for full
file path. Use a variable pointer $uploadFile.
Improves code readability and robustness.
|
|
As phpmd (PHP Mess Detector) linter says: "An if expression with an else
branch is never necessary." Well, at least almost never necessary.
Improves readability and resolves phpmd cleancode lint errors.
|
|
camelCase is the preferred coding style for function names in the PSR-2
coding style guide used by Pomf since version 2.0.0.
Reference: http://www.php-fig.org/psr/psr-2/
|
|
There are two issues with get_sha1():
- The function name doesn't follow the PSR-2 coding style guide for
function naming, followed in Pomf since version 2.0.0.
- SHA-1 is no longer considered resilient to collisions, versus SHA-256.
In current plans, this feature is to be replaced with getHash() or
similar function name in the next major version (Pomf 3.0.0).
For consideration for future SHA-256 hashing implementation, the MySQL
schema's hash value needs to be changed from char(40) to char(64) to
accommodate the longer SHA-256 length of 64 bytes in hexadecimal string.
|
|
File expiration support has never been properly implemented in Pomf core
or moe panel. It serves as legacy baggage before nekunekus got an idea
to create nokonoko/Uguu for temporary uploads.
In current plans, this non-feature will be removed in the 3.0.0 release
which is the next SemVer major version that allows to remove this.
Reviewed-by: Austin Gillmann <alucard@cuntflaps.me>
|
|
As explained by clsr:
> <clsr> With default PHP settings, that'd print a warning, then treat
> $result as if it was an empty string before appending.
This bug was introduced in commit
a92961f24072bc4c3881bf0e2f609562f3703471 and
1411bce1dc13bf6fea66b5899ba29d50d5c53bb0.
Reported-by: clsr <clsr@clsr.net>
Suggested-by: clsr <clsr@clsr.net>
|
|
Right before text_error(), there was a missing newline. This bug was
introduced in commit a92961f24072bc4c3881bf0e2f609562f3703471.
|
|
New code has been added to Response.class.php this year in commit
b94ac9a. Update LICENSE and Response.class.php copyright header with
year 2016.
We can't do this for every file in the project repository unless they
are actually changed, due to the way our copyright legislation works. We
also can't remove the mention of 2015, because most of the code was
initially published in 2015 and so remains copyrighted since that year.
|
|
Clean up a lot of the cruft in Response class.
Gyazo is deprecated and falls back to 'text' for similar functionality,
reducing code duplication. It will be removed in a future release.
CSV gets a text/csv Content-Type. CSV linebreaks are also now CRLF, and
values are wrapped in quotes.
The default error is now a JSON response instead of a generic 400 Bad
Request in plaintext.
output=json is now explicit and no longer undefined behavior.
|
|
The gyazo response would return an empty response, because the construct
didn't actually fallthrough to text properly. Force gyazo's response
type to be 'text' to fix the issue.
Accordingly, the 'gyazo' cases for send() and error() now become dead
code. Remove them.
OK ewhal@
|
|
(Partially reverts commit e0bb4e0.)
Actually fix generate_name() COUNT query this time. It still had an
imaginary table "pomf" from e0bb4e0. Change it to "files" like in the
schema.
For code consistency, :filename is reverted back to :name as it was
before commit e0bb4e0. That commit is bogus and doesn't fix the issue
due to skipping the code review process.
The problem with this COUNT query in first place was that it checked
imaginary columns (name) from an imaginary table (pomf) in the database.
This led to the "same filename" check not working at all, and the other
code only relying on checking the same hash (currently SHA-1) for
returning the filename before generate_name().
By luck, generated filenames could collide and another file of the same
generated filename would be returned, discarding the new upload.
I discovered this bug about a month ago myself, but back then there was
no reliable way to reproduce it and no good description of the bug.
This bug was introduced in commit 5b77a4e.
Reported-by: Vhum Vhum <vhumvhum1@gmail.com>
Suggested-by: Luminarys <luminarys@fuwa.se>
OK ewhal@, luminarys@
|
|
database
|
|
Validate CSV responses by wrapping them in double quotes and using CRLF
linebreaks.
CRLF linebreaks are used to conform RFC 4180. Double quotes can be
useful to avoid subtle bugs and validation errors.
This code is ugly. For future improvement, something like arrays could
be used or dropping support for CSV API completely.
Vague OKs from ewhal@, luminarys@
|
|
To understand and document the API, responses should be correct,
accurate and human readable. Server-side compression (gzip) will
compensate for the extra whitespace.
OK ewhal@
|
|
Code re-use is good. The previous implementation doesn't reuse existing
text_error() functions and also forgoes using text/plain header with the
text implementation.
This fixes consistency where JSON is assumed to be the default output.
It is a common practice among APIs to default all errors to JSON, such
as the Stripe and Tumblr APIs.
|
|
It is a little unclear what the deprecation warning wants the developer
to do. The fallthrough comment to text response may not be immediately
obvious to the reader.
This commit helps to understand the intention and to avoid bugs such as
commit daac77a.
|
|
Gyazo didn't fallthrough correctly to text, because the type would be
set to Gyazo while the Gyazo case didn't exist. PHP is so ambiguous
sometimes.
This adds the missing fallthroughs that were removed in commit e39a920.
It should now correctly fallthrough ("fallback") to text response.
|
|
While double quotes are mostly optional in implementations, some CSV
linters want double quotes for whatever the reason. Assumably, it
reduces the amount of bugs and avoids possible parsing errors. This also
has very little relevance for not trusting the user input, but better be
safe than sorry.
This commit is not very pretty. In a future commit, this issue will be
addressed with arrays and fputcsv().
|
|
RFC 4180 specifies that CSV files should use CRLF (a carriage-return and
line-feed pair, e.g. \r\n).
|
|
This fixes a silly mistake where Gyazo would accidentally use the HTML
response instead of text as intended.
This bug was introduced in commit 2ca5b6b.
|
|
This commit improves readability and compliments commit 6d8b204.
|
|
This commit improves readability.
|
|
Let's say some user decides to use output "xml". Unexpectedly, the user
would instead receive JSON output. This is undefined behavior in its own
way and violates the principle of least surprise.
Problems could arise if we added "xml" later with actual application/xml
or text/xml content.
Right now upload.php overrides an empty output argument to json instead,
so this seems safe to do. Any non-existent output will now return a 400
Bad Request error.
|
|
This commit improves readability by swapping text and html response
source line order for alphabetical sorting.
|
|
This restores the typical sorting order:
- csv
- (gyazo)
- text
- html
- default (json)
|
|
A majority of the Gyazo code is just copy-pasted text/plain protocol.
This will put an end to that insanity.
OK ewhal@
|
|
Previously, CSV would return the wrong filetype text/plain and
fallthrough.
RFC 4180 registers text/csv MIME type. RFC 7111 is closely related and
says to use text/csv to launch the correct application.
|
|
OK ewhal@
|
|
Moe panel uses PHP sessions to keep the user logged in. We don't need it
anymore, it's not required for core functionality.
|
|
OK ewhal@
|
|
get_crc32() was removed in commit ea6a7a0194 and never in use in the
code. It seems Eric forgot to remove this property.
|
|
|
|
|
|
|
|
Remove non-free images
|
|
|
|
Interestingly, static/classes/UploadedFile.class.php is not licensed
under Expat license. Because it was posted in PHP.net comments, I
believe it's under the PHP license.
|
|
|
|
IANA has registered UTF-8 as uppercase, hyphenated. The RFC concerning
UTF-8, RFC 3629 also uses this grammar.
RFC 2231 says the Content-Type charset value should be:
charset := <registered character set name>
RFC 5987 further emphasizes this:
charset = "UTF-8" / "ISO-8859-1" / mime-charset
Therefore lowercase "utf-8" in Content-Type responses is technically
incorrect, but case-insensitive according to RFC 2616.
Thanks to pantsucat for researching this with me.
|
|
|
|
|
|
These commits are ShareX issues, not Pomf issues. Allowing these
commits to be in the source reduces maintainability.
This reverts commits bbcffe8d745937677352edf25e6a250ca8fd507b,
943e7e62a8ca814d47168bcebf2cc92dbce9a45a and partially
1411bce1dc13bf6fea66b5899ba29d50d5c53bb0.
|
|
|
|
|
|
|
|
|
|
PSR-2 [1] is a highly regarded style guide in the PHP community
according to Stack Overflow [2].
The indentation was out of place in the source code. I've seen a
combination of 1 space tabs, 3 space tabs, 4 space tabs and 5 space
tabs. Some closing braces on the same line and a lot of the code
(especially moe code) had reached the point of losing readability.
Converted with php-cs-fixer and some hand adjustment.
[1]: http://www.php-fig.org/psr/psr-2/
[2]: https://stackoverflow.com/questions/3638083/list-of-highly-regarded
-php-style-guides
|
|
|
|
Adds a new config option POMF_FILES_LENGTH. This will allow the user to
adjust the length of filenames. Defaults to 6.
The filename generator never used character z in new filenames. There
are 27 characters in a-z, but the old code uses a magic number of 26
characters. This bug was introduced in commit
5b77a4eaab418836820b2a0bad7c88f0b88136a0.
Instead of relying on magic numbers like with mt_rand(), conveniently
use arrays with array_rand() instead. More characters can be added with
array_merge() in future if desired.
|
