| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This might have broken the screenshot uploader on some crappy browsers,
but it's much cleaner than the old iframe hack. The ability to upload
multiple files in one go is also very convenient.
|
|
The intention is to move more JS editing forms to use JSON, but manually
verifying JSON objects is both painful and likely to introduce errors or
vulnerabilities. json_validate() is a bit of a hack, but has the
advantage that its validation syntax is the same as for normal forms,
and it automatically strips whitespace. I intent to give kv_validate()
an upgrade to be more flexible/modular so it can do more custom
normalization. But that's for later.
I've been meaning to rewrite the JS forms anyway together with the large
JS rewrite, but I'm rather lazy. This is one small step in the right
direction anyway.
Note that json_validate() assumes that the JS code will provide
user-friendly messages on bad input, but the staff alias editor doesn't
quite do this yet.
|
|
|
|
And also fix strip_bb_tags() to be case-insensitive and fix a bug in
converting the query into a tsquery.
|
|
Inspired by wakaranai's implementation at
https://github.com/morkt/vndb/commit/b852c87ad145fdaaa09c79b6378dd819b46f7e87
This version is different in a number of aspects:
- Separate search functions for title search and fulltext post search.
Perhaps not the most convenient option, but the downside of a combined
search is that if the query matches the threads' title, then all of
the posts in that thread will show up in the results. This didn't seem
very useful.
- Sorting is based purely on post date. Rank-based sort is slow without
a separate caching column, and in my opinion not all that useful.
Implementation differences:
- Integrated in the existing DB::Discussions functions, so less code to
maintain and more code reuse.
- No separate caching column for the tsvector, a functional index is
used instead. This is a bit slower (index results need to be
re-checked against the actual messages, hence the slowdown), but has
the advantage of smaller database dumps and less complexity in
updating the cache.
Things to fix or look at:
- Highlighting of the search query in message contents.
- Allow or-style query matching
|
|
The char(2) solution is both inefficient and ugly. Also needed to be
careful with handling the extra space that Postgres would automatically
add to single-character types.
|
|
It's not a preference yet and the sexual traits are still visible by
default. I'll fix that later.
|
|
Having a proper and up-to-date list of moderators is an often requested
feature.
|
|
(Quoting mail:)
- character list is sorted by name in cast edit form (managing of the
huge lists like v6458 becomes slightly easier);
- display number of characters voiced on seiyuu page;
- display a notice in staff edit form when primary name could be
changed.
|
|
|
|
The new alias editing interface makes it a lot easier to change the
primary name.
|
|
|
|
|
|
|
|
|
|
To fix an issue mentioned in <https://vndb.org/t6138.15>. Yay for
writing patches on the live site.
|
|
Conflicts:
lib/VNDB/DB/VN.pm
lib/VNDB/Handler/VNPage.pm
|
|
|
|
|
|
This happened when a release was linked to multiple visual novel
entries, the language icon would show on one VN but not on the other.
|
|
|
|
|
|
This unfortunately means I had to remove the order-by-character-role
feature. It's possible to get that back, but it's not quite as trivial.
|
|
|
|
|
|
|
|
- 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
|
|
And call bbSubstLinks() from Handler::Discussions rather than
DB::Discussions - it's not a transformation that the DB layer should do,
IMO.
|
|
Patch from https://vndb.org/t5564.13
|
|
|
|
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.
|
|
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.
|
|
|
|
Fixes http://vndb.org/t5136
|
|
I think this is the only thing necessary to add full IPv6 support to
VNDB. It's not actually necessary, but without this modification it will
become way too easy to flood the site with new accounts.
|
|
|
|
|
|
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.
|
|
This is under the assumption that earlier releases are added earlier,
even when they're released on the same date. (E.g. in the case of v9678)
|
|
I rather dislike GROUP BY on a large query and scary combinations of
LEFT JOINs and regular JOINs. As expected from Postgres, subquery joins
are quite fast. :D
|
|
|
|
|
|
The interface to set a non-integer vote isn't very nice, but at least it
works. Or so I hope.
|
|
|
|
|
|
|
