Age | Commit message (Collapse) | Author | Files | Lines |
|
This removes one source of namespace polution, and makes it more clear
which code is using the variables.
|
|
First part of a Javascript cleanup.
|
|
|
|
This fixes the unexpected behaviour that changing the spoiler setting on
one page will change it for all pages. All manual spoiler changing
options are temporary now.
|
|
The name of the profile setting isn't very clear. Not sure what to do
with it.
|
|
|
|
It's a relic of the past. IE 6 & 7 are very rarely used nowadays, and
people still using it will quickly realize why things don't quite work -
they'll be used to it.
|
|
|
|
|
|
https://vndb.org/t6138.226 - https://vndb.org/t6048.132
|
|
|
|
|
|
It became a bit of a hassle to keep updating that file manually in Gimp.
This script performs surprisingly well for our set of icons.
|
|
Note that it's still in the postgresql ENUM type. Removing that is
possible, but not very trivial.
|
|
|
|
So that the /util/sql/ files are in sync with the actual DB again.
|
|
Conflicts:
lib/VNDB/DB/VN.pm
lib/VNDB/Handler/VNPage.pm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Moves staff<->vn linking form to the main VN edit form
- Fixes a bug with linking staff aliases to VNs
- Adds staff changes to the VN revisions
- And some misc. improvements
|
|
|
|
Used to link to a visual-novels.net review or something. Links have been
hidden and dead since ages. No need to keep the column around.
|
|
|
|
This ensures that, if an attacker evers gets read access to the
database, he will not be able to compromise any accounts. SHA-1 suffices
here, because the data being hashed is a random 20 byte string. The
search space is so damn large that you can't sanely brute force it, nor
are rainbow tables any use at that scale.
They're not salted. The password reset tokens are also hashed in the
database and do include salt, but I've no idea why we did that.
|
|
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).
|
|
It doesn't make a whole lot to separate the hashed password and the salt
from each other, you need both to do anything with them, and from the
database perspective they're both completely opaque strings only usable
for direct comparison with other hashed strings.
This change is mostly as preparation for switching to a proper key
derivation function (sha256 isn't...) and to add support for longer
and/or binary salt.
Because the passwd field now needs to be interpreted in Perl, it's being
passed around as a binary string rather than a hex-encoded value.
API login is broken in this commit. I'll get to that.
|
|
I believe I didn't do this conversion earlier (back when I converted the
language types) because PostgreSQL didn't support dynamically adding new
values to an existing enum back then, and modifying an enum was a huge
pain. Recent versions do support this, so there's no reason to keep it
as a string.
...I just felt like adding some churn to the code base.
|
|
Easier to work with in custom queries.
|
|
Suggested by Hinoe, quoting his reasoning:
In popularity rankings, change the normalization from
"sqrt(LowerVoteCount)" == "LowerVoteCount^0.5" to something that grows
somewhat more slowly.
Details: Natural logarithm itself (ln(LowerVoteCount+1)) is too slow;
at the current VN count (15403), it returns 9.64; however, sqrt(15402)
is just above 124.1, which I feel is already too high. After
experimenting with the exponents a bit, I decided that the best point
likely lies between 0.3, which returns a bit above 18.0, and 0.4,
which returns a bit above 47.3. Thus, I suggest that the new function
be LowerVoteCount^0.36788; the exponent is a 5-digit approximation of
e^-1, just because it's a nice number in the specified area and works
well, returning circa 34.7.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes http://vndb.org/t4105
|
|
|
|
All the async stuff isn't necessary now that images are processed
synchronously.
|
|
TODO: Get rid of the 'processing' flag and all the async loading of
screenshot data in the screenshot uploader.
|
|
|
|
I used to do this to avoid loading Image::Magick in each TUWF process,
decreasing memory usage, and lowering the blocking time by avoiding too
much processing. Memory isn't much of a problem nowadays, and processing
images is fast enough, too, so this complexity isn't necessary anymore.
(Character images and screenshots pending)
|
|
|
|
The ordering unfortunately matters for some tables, due to the edit_*
stored procedures relying on it. :-(
|
|
|
|
|