Age | Commit message (Collapse) | Author | Files | Lines |
|
Fixes https://vndb.org/t2520.229
|
|
|
|
https://vndb.org/t950.339
|
|
Fixes https://vndb.org/t2520.222
|
|
This makes the relation graphs useful again for several large (mostly)
independent graphs that are sometimes linked together by unofficial
relations.
e.g. https://vndb.org/t8985
|
|
Fixes https://vndb.org/t2520.215
|
|
|
|
Fixes https://vndb.org/t2520.213
|
|
https://vndb.org/t2520.209
|
|
https://vndb.org/t2520.210
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
The names of the staff were fetched from the existing VN entry, so any
newly added staff were not present in that list, and would thus not
show up when the form validation failed.
This fix makes sure to always fetch the required data from the database.
|
|
This is a generalization of the search improvements made in
7da2edeaa0f6cf7794f4f8f68960497dc1be893c and
92235222dba4e5d0c7713d53ef12e0f10e371b83
And has been applied to the dropdown searches for producers, staff, tags
and traits.
For all those searches, exact matches are listed first, followed by
prefix matches, and then substring matches. Relevance is currently only
based on the primary name/title and ignores aliases (except for staff).
This is fixable, but not trivial, and I'm not sure it's all that useful.
|
|
|
|
- Exact match is now case-insensitive
- Main staff search supports exact match with =-prefix
- On VN edit dropdown: exact matches are sorted before other matches
- VN edit dropdown now also displays original name
|
|
|
|
|
|
|
|
|
|
- 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
|
|
|
|
Most of these replacements were automated. This ended up being less
work than I had anticipated.
I also fixed a few minor bugs along the way, but probably introduced
more than I fixed.
|
|
With some related edits in other parts of the code, mostly due to
interface changes to htmlRevision() and htmlFormError().
Trivial replacements were automated by a super awesome script.
|
|
|
|
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The comment already suggested this:
I wonder whether it's better to just ask database for character list
instead of doing this manual group/sort
So yeah, let's just do that.
|
|
|
|
|
|
|
|
The styling of the staff info can be a bit awkward at times, but it
looks slightly better than a table, IMO. I didn't really know what to do
with the the seiyuu info - it wastes a lot of screen space in its
current implementation, but I can't think of anything better at the
moment.
|
|
|
|
- Merged polls table into threads table. Not much of a
storage/performance difference, and it's a bit simpler this way.
- Merged DB::Polls into DB::Discussions. Mainly because of the above
change in DB structure.
- Add option to remove an existing poll.
- Allow preview and recast to be changed without deleting the votes
- Set preview option by default. Because personal preferences. :)
- Minor form validation differences
|
|
|
|
|
|
Having the time display is quite useful. It does make the listings look
more cluttered, but meh.
|
|
|