| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
It's not verified and only uglifies the URLs.
|
|
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
|
|
Reported by dim0k at https://www.xssposed.org/incidents/74523/
|
|
|
|
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.
|
|
Not entirely sure if this is an improvement, but it's slightly more
consistent with other layouts (combination of user page, release page
and character page), and leaves more room for the credit/cast listings.
|
|
|
|
|
|
|
|
Conflicts:
lib/VNDB/DB/VN.pm
lib/VNDB/Handler/VNPage.pm
|
|
|
|
|
|
Patch from https://vndb.org/t2520.116
|
|
|
|
Patch from https://vndb.org/t5564.18
|
|
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
|
|
|
|
This also simplifies the code a bit, as the value of the preference data
was never used so doesn't need to be included now. Primary reason for
this change is to work towards disabling inline JS with a CSP header.
There's still more stuff to fix before the CSP header can be applied,
though.
|
|
TUWF properly detects HTTPS and includes this in the returned URL, so
this change ensures that all URLs adopt properly to HTTP and HTTPS.
|
|
Per https://vndb.org/t5864
|
|
|
|
|
|
This should result in a more natural tabbing order, skipping over any
links around the forms.
|
|
|
|
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.
|
|
|
|
formcode is strengthened by including the IP (-prefix) into the hash,
ensuring that the code can't be obtained by someone on a different
network.
I also removed the login form of every page. Felt kinda pointless.
|
|
|
|
|
|
|
|
Using CSS3 selectors. This is a more elegant approach, and since browser
support for CSS3 selectors isn't as crap as it used to be I can finally
make use of them.
|
|
The interface to set a non-integer vote isn't very nice, but at least it
works. Or so I hope.
|
|
|
|
|
|
|
|
|
|
|
|
Rather than setting an automatically password, reset the password and
send an email with a secure token instead. The password can then be set
again using this token.
This doesn't really have an advantage at this point, just makes the
interface and code more consistent when I update the registration code
to do something similar.
|
|
Users who haven't logged in since 2009-08-09 will find that their
passwords have been reset. They need to use the password recovery
feature before logging in again.
|
|
This makes the denied trait listing useful again.
|
|
Algorithm::Diff::Fast suddenly disappeared for some reason...
|
|
|
