* Users are only authenticated against their password on login,
and to retrieve a token
* Passwords are wiped from the GUI frontend and cookies
after login and token retrieval
* Tokens are revoked at the end of the session/logout
* If the user chooses the "remember me" option,
the token is stored in the cookie
* Tokens correctly delete themselves on logout
* Tokens can expire at user-specified date
* Tokens have their last usage time
* Tokens can have user defined descriptions
* Users can manage login tokens in their account settings
- Changed password setup to use libsodium and argon2id (regular SHA256
hashing for passwords is inadequate as modern GPU's can hash generate
billions of hashes per second).
- Added code to auto migrate old passwords to the new password_hash if
the existing password_hash matches either of the legacy password
generation schemes (SHA1 or SHA256).
- Added migration to support new password_hash format length
- Added column password_revision. This field will default to 0, which
all passwords will have till they're updated. After that each password
hash method has a revision.
- Default setting is false for both conversions, as this will require
additional resources of the server, but is bandwidth friendly for
viewers
- WEBM conversion is slow, but better quality than MP4 conversion with
a typically smaller file size
- Tags are copied over from the original upload
- Snapshots are generated for the new auto posts
Poorly formatted MP4 and WEBM sources can cause ffmpeg to throw a lot
of warnings. However when there is byte ouptut, the generated thumbnail
is valid. Add a bypass for the resize_fill function to allow ffmpeg to
error.
* Added functionality for administrators to directly add users to the
application
* Added permission users:create:any to handle level that users are
allowed to create other users
* Moved old permission users:create to users:create:self
- Added type hinting (for now, 3.5-compatible)
- Split `db` namespace into `db` module and `model` namespace
- Changed elastic search to be created lazily for each operation
- Changed to class based approach in entity serialization to allow
stronger typing
- Removed `required` argument from `context.get_*` family of functions;
now it's implied if `default` argument is omitted
- Changed `unalias_dict` implementation to use less magic inputs
While I hold this library in great esteem for its excellent work on
implementing the original paper, I have several problems with it:
- as of this commit, it (again) has bug fixes unreleased on pip
- its code is badly structured
- forces OOP and then proceeds @staticmethod everything
- bad class design, parameters are repeated in several places
- terrible contract of make_record() and generate_signature()
- ambiguous parameters: path vs. image path vs. image content
- doesn't adhere to PEP-8
- depends on cairo just to render svg images almost no one uses this
library with
In the post list, when we navigate to the page with ">" button, we
navigate to older posts.
In the post view, when we navigate to the page with ">" button, we
navigate to older posts as well.
However, in the post list, the ">" button is called "next page".
At the same time, in the post view, the ">" button was called "previous
post". Now it's called "next post".
The difference isn't visible to normal users nor even API consumers as
the "get posts around post X" request isn't documented.
The change is motivated not only by consistency, but to also improve
compatibility with Vimperator's `[[` and `]]`. Vimperator assumes the
word "next" refers to ">" and the word "previous" refers to "<".
Let range criteria (values that contain ..) that end up being used as
strings, to be used as if they were simple criteria. So let the user
search for "when_you_see_it..." and don't throw a warning.
The better implementation of a224297.
Fixes ability to reorder tag aliases, especially - the ability to change
the tag's primary name after it was created. Until now, both of these
scenarios needed sad workarounds on the user part.
Entering:
miko -miko
is a contradiction that shouldn't have been returning any matches, but
it has nonetheless. This change fixes the construction of negated
expressions that use subqueries.
- Don't cache default category in its entirety - cache only its name
- Purge cache on category name changes and default category changes
- Lock records for updates where applicable
Using sqlalchemy's subqueryload to fetch tags works like this:
1. Get basic info about posts with query X
2. Copy query X
3. SELECT all tags WHERE post_id IN (SELECT post_ids FROM query X)
4. Associate the resulting tags with the posts
When original query contains .order_by(func.random()), it looks like
this:
1. SELECT post.* FROM post ORDER BY random() LIMIT 10
2. Copy "ORDER BY random() LIMIT 10"
3. SELECT tag.* FROM tag WHERE tag.post_id IN (
SELECT id FROM post ORDER BY random() LIMIT 10)
4. Disaster! Each post now has completely arbitrary tags!
To circumvent this, we replace eager loading with lazy loading. This
generates one extra query for each result row, but it has no chance of
producing such anomalies. This behavior is activated only for
queries containing "sort:random" and derivatives so it shouldn't hit
performance too much.
Rather than flushing the post right away only to find out that there
were validation errors, try to postpone flushing for as long as
possible.
The previous behavior has led to too eager spending of post IDs - each
flush calls nextval(post_id_seq), and postgres sequences are not
affected by transaction rollbacks, so each erroneous post creation
discarded a post ID, which has led to gaps in post IDs.
This changes the checksums to ones that are compatible with 1.x, which
relieves the migration script from recalculating the checksums for all
the posts.
Ignored only the rules about continuing / hanging indentation.
Also, added __init__.py to tests so that pylint discovers them. (I don't
buy pytest's BS about installing your package.)
For quite some time, I hated Falcon's class maps approach that caused
more chaos than good for Szurubooru. I've taken a look at the other
frameworks (hug, flask, etc) again, but they all looked too
bloated/over-engineered. I decided to just talk to WSGI myself.
Regex-based routing may not be the fastest in the world, but I'm fine
with response time of 10 ms for cached /posts.
