| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
https://vndb.org/t950.317
|
|
|
|
|
|
Previously the website was connected to the database with a "database
owner" user, which has far too many permissions. Now there's a special
vndb_site user with only the necessary permissions. The primary
reason to do this is to decrease the impact if the site process is
compromised. E.g. it's now no longer possible to delete or modify old
entry revisions. An attacker can still do a lot of damage, however.
Additionally (and this was the main reason to implement this change in
the first place), the user sessions, passwords and email data is now not
easily accessible anymore. Hopefully, the new user management
abstractions will prevent email and password dumps in case of an SQL
injection or RCE vulnerability in the site code. Of course, this only
works if my implementation is fully correct and there's no privilige
escalation vulnerability somewhere.
Furthermore, changing your password now invalidates any existing
sessions, and the password reset function is disabled for 'usermods'
(because usermods can list email addresses from the database, and the
password reset function could still allow an attacker to gain access to
anyone's account).
I also changed the format of the password reset tokens, as they totally
don't need to be salted.
|
|
|
|
|
|
|
|
- Fix mouse-over text of language flag on homepage
- Capitalize release types in edit form
- Use plural form of character roles on VN page listing
|
|
|
|
I definitely needed the Tie::IxHash thing for these.
|
|
This removes the reliance on sort() to provide meaningful ordering (the
keys aren't always good for ordering) and removes the 'order' hack used
for (vn|prod)_relations.
|
|
Now that graphviz knows the actual strings, it has a better opportunity
to create better graphs.
(Most of them still look messy tho)
|
|
|
|
|
|
Compresses a little better. I reduced the number of iterations required
to find the optimal image size in spritegen.pl, but generating the
icons.png is *incredibly slow* when combining zopflipng with the 'slow'
option. It's possible to parallelize the calculation and use multiple
cores to speed it up, but that seems overkill.
Some icons.png compression stats:
METHOD SIZE RUNTIME
default 18103 <1sec
slow 17941 few secs
pngcrush 15385 <1sec
pngcrush+slow 15148 few mins
zopflipng 14986 few secs
zopflipng+slow 14898 ~1 hour
|
|
|
|
They had to be deleted from the database at some point, otherwise we
still have thousands of easily-cracked password hashes in the database.
Note that I could have opted to use scrypt on top of the sha256 hashes
so the passwords would remain secure without needing to reset
everything, but doing that after one year of switching to scrypt is
likely not worth it. Everyone who still actively uses his account has
already been converted to scrypt, everyone else should just reset their
password whevener they decide to come back.
|
|
|
|
|
|
A recent version of imagemagick creates 16 bit depth PNG images by
default for some reason. This results in an unnecessarily large file
size increase and pngcrush doesn't do much to counter it (and its
-bit_depth option has been deprecated, too).
The atomic replace is quite handy to avoid people seeing any wierd
intermediate images while the slow+pngcrush options are being used.
|
|
Tends to compress a bit better than JavaScript::Minifier::JS. But is
also a lot slower, so not really useful when devving.
Stats for en.js:
raw gzip
uglifyjs 68199 19446
JS::Minifier::XS 79862 21624
Uncompressed 107662 28663
On an unrelated note, I like how jQuery boasts about being "Only 32kB
minified and gzipped.". That's quite a bit more than all of VNDB's
Javascript combined. For a damn library.
|
|
This simplifies the JS version of mt() a bit and makes the whole
internationalization framework a bit more robust. I also changed the
VARS.{rlist_status,age_ratings,languages,platforms,char_roles} arrays to
include the L10N string. This simplifies the JS code and reduces the JS
size. There's a few more of such lists that can be transformed in the
same way, I'll get to that later.
|
|
The name of the profile setting isn't very clear. Not sure what to do
with it.
|
|
Having a proper and up-to-date list of moderators is an often requested
feature.
|
|
https://vndb.org/t6138.226 - https://vndb.org/t6048.132
|
|
|
|
|
|
Let's see how this goes.
|
|
Note that it's still in the postgresql ENUM type. Removing that is
possible, but not very trivial.
|
|
Conflicts:
lib/Multi/Feed.pm
lib/Multi/IRC.pm
|
|
I probably don't want to have the 'trace' log level on the actual
server.
|
|
|
|
|
|
|
|
|
|
TUWF properly detects HTTPS and includes this in the returned URL, so
this change ensures that all URLs adopt properly to HTTP and HTTPS.
|
|
|
|
Completely disregard my comments regarding DoS in commit
6e0a0e1d00e11da9b4eab2163e19314f752b05b5 - successful logins aren't
throttled at all. The other reason for lowering this value is because
the API requires a login for each new TCP session, and it doesn't seem
like many (any?) applications keep the TCP session alive for very long.
Still, 65536 is more secure than the default of 16384.
|
|
I increased the N parameter to approximate about 500ms to generate the
hash. This is quite a paranoid setting for a website, but login attempts
are throttled so there's not much of a DoS factor. (Alright, password
changing feature isn't throttled so the DoS factor still exists. But
really, there's some pages with longer page generation times anyway.)
I did lower the size of the salt a bit (Crypt::ScryptKDF uses 256 bits
by default), because 64 bits of randomness should have low enough chance
of collision with only ~100k users (even with a million users,
seriously).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TODO: Get rid of the 'processing' flag and all the async loading of
screenshot data in the screenshot uploader.
|
|
This isn't documented yet.
|
