#179 Implement Miniflux

Open
opened 4 weeks ago by jking · 0 comments
jking commented 4 weeks ago

Reference: https://miniflux.app/docs/api.html

The reference would seem to be vague on a number of points; questions and answers will be gathered here as I work through it.

Input handling

Miniflux does not return 415 Unsupported Media Type responses when given input in a media type other than JSON (for example, a text/html document which is indistinguishable from a valid JSON document will be accepted). Presumably the same is true for OPML import, where any input is treated as XML regardless of media type.

Unknown routes

If attempting to access an unimplemented URL, a 405 Method Not Allowed with no body is returned rather than a 404 Not Found response. Moreover, 405 is not listed in the documentation as a possible error code.

Authentication

Miniflux has two authentication schemes: standard HTTP Basic authentication, and API tokens. These tokens are 32-byte random strings, base64url-encoded, which are sent via an X-Auth-Token header field. Tokens are checked first, then HTTP credentials; thus an invalid token combined with valid HTTP authorization will yield a 401 response. Likwise, a token for User B will take precedence over credentials for User A. If multiple X-Auth-Token header-fields are specified the first is used, even if it is blank.

Version and health check

Both the /version and /healthcheck routes are unversioned (note the lack of /v1 prefix), do not require authentication (credentials are not even validated), and simply return text/plain constant values (the current version number and the string “OK”, respectively). Given this they should probably be implemented separately for simplicity’s sake.

Discovery

Miniflux will discover multiple feeds, and will essentially return its input if given a feed URL.

Get feeds

There are extra fields not listed in the documentation:

  • next_check_at: RFC 3339 timestamp, presumably of when the feed will next be checked, though min were borked
  • user_agent: The custom per-feed UA string; we’re not likely to support this
  • disabled: A boolean, a refrection of the “Do not refresh this feed” checkbox
  • ignore_http_cache: A boolean
  • fetch_via_proxy: A boolean
  • category: A JSON object representing the folder the feed is in, which has id, title, and user_id (the user number). Uncategorized feeds go into an “All” folder with ID number 1; we’ll try giving it ID number 0 and hope clients don’t break
Reference: https://miniflux.app/docs/api.html The reference would seem to be vague on a number of points; questions and answers will be gathered here as I work through it. ## Input handling Miniflux does not return `415 Unsupported Media Type` responses when given input in a media type other than JSON (for example, a `text/html` document which is indistinguishable from a valid JSON document will be accepted). Presumably the same is true for OPML import, where any input is treated as XML regardless of media type. ## Unknown routes If attempting to access an unimplemented URL, a `405 Method Not Allowed` with no body is returned rather than a `404 Not Found` response. Moreover, `405` is not listed in the documentation as a possible error code. ## Authentication Miniflux has two authentication schemes: standard HTTP Basic authentication, and API tokens. These tokens are 32-byte random strings, base64url-encoded, which are sent via an `X-Auth-Token` header field. Tokens are checked first, then HTTP credentials; thus an invalid token combined with valid HTTP authorization will yield a `401` response. Likwise, a token for User B will take precedence over credentials for User A. If multiple `X-Auth-Token` header-fields are specified the first is used, even if it is blank. ## Version and health check Both the `/version` and `/healthcheck` routes are unversioned (note the lack of `/v1` prefix), do not require authentication (credentials are not even validated), and simply return `text/plain` constant values (the current version number and the string "OK", respectively). Given this they should probably be implemented separately for simplicity's sake. ## Discovery Miniflux will discover multiple feeds, and will essentially return its input if given a feed URL. ## Get feeds There are extra fields not listed in the documentation: - `next_check_at`: RFC 3339 timestamp, presumably of when the feed will next be checked, though min were borked - `user_agent`: The custom per-feed UA string; we're not likely to support this - `disabled`: A boolean, a refrection of the "Do not refresh this feed" checkbox - `ignore_http_cache`: A boolean - `fetch_via_proxy`: A boolean - `category`: A JSON object representing the folder the feed is in, which has `id`, `title`, and `user_id` (the user number). Uncategorized feeds go into an "All" folder with ID number 1; we'll try giving it ID number 0 and hope clients don't break
jking added this to the 0.9.0 milestone 4 weeks ago
jking added the
api
label 4 weeks ago
jking added a new dependency 3 weeks ago
jking added a new dependency 3 weeks ago
jking added a new dependency 3 weeks ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Depends on
#180 User metadata
MensBeam/arsse
#178 Storing blobs in PostgreSQL
MensBeam/arsse
#177 Icon cache
MensBeam/arsse
Loading…
There is no content yet.