It is not aimed to test if we can get the full article (since we aren't using real login/password)
but mostly to test the full work (with authentication, etc.)
Do not clean fixtured to avoid SQLite to re-use id for entry tag relation 😓
Listing entries can now be filtered by “public”.
Creating or patching an entry can now set is to public or remove the public.
Entry response now include “is_public” boolean field
Instead of saving the value of each field right into the content without any validation, it seems better to validate them.
This might sounds obvious now we say that.
While creating a new user using the API, we also create a new client for the current user.
So the app which just create the user can use its newly created client to configure the app.
That new client is only return after creating the user.
When calling the endpoint /api/user to get user information, the new client information won’t be return.
When parsing content to retrieve images to save locally, we only check for the content-type of the image response.
In some case, that value is empty.
Now we’re also checking for the first few bytes of the content as an alternative to detect if it’s an image wallabag can handle.
We might get higher image supports using that alternative method.
I've added a toggle feature (in internal settings) so that user api creation can be disabled while form registration still can be enabled.
Also, the /api/user endpoint shouldn't require authentication. Even if we check the authentication when sending a GET request, to retrieve current user information.
I've moved all the internal settings definition to config to avoid duplicated place to define them.
I don't know why we didn't did that earlier.
