core: Replace legacy INI config system with Pydantic-based TOML configuration.
This is a huge configuration refactoring. The configuration system now uses Pydantic settings, with better validation, better support for environment variables and other goodies. The main config files now use TOML instead of INI, this allow for better handling of complex types, notably dict. Plugins, components and frontends can declare their config settings in a class which will be imported dynamically.
This commit is contained in:
Goffi
parent
f3f40848b3
commit
6a7b7bc36a
59 changed files with 1392 additions and 1011 deletions
|
|
@ -104,7 +104,7 @@ entities (JIDs). Permissions can be set through Ad-Hoc Commands.
|
|||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
All options are to be set in ``[component file-sharing]`` section.
|
||||
All options are to be set in ``[components.file_sharing]`` section.
|
||||
|
||||
``http_upload_port``
|
||||
port to use for HTTP File Upload
|
||||
|
|
@ -181,148 +181,7 @@ documentation to find how this must be done.
|
|||
Configuration
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
All options are to be set in ``[component ap-gateway]`` section.
|
||||
|
||||
``public_url``
|
||||
Main user-facing domain of the HTTP server, this will be used to construct all AP URLs
|
||||
|
||||
**default**: if not set, ``xmpp_domain`` is used. If ``xmpp_domain`` is not set either,
|
||||
an error is raised.
|
||||
|
||||
``http_port``
|
||||
port where the HTTP server should listen. Port ``80`` is not used directly as it would
|
||||
require root privileges, and it is strongly recommended against launching Libervia under
|
||||
a privileged account. An HTTP Proxy or a port redirection should be set to redirect the
|
||||
``80`` port to the port specified here.
|
||||
|
||||
**default**: ``8123``
|
||||
|
||||
``http_connection_type``
|
||||
either ``http`` or ``https``. If you have a HTTP proxy such as Apache or NGINX which
|
||||
already handles HTTPS, you may want to use ``http``.
|
||||
|
||||
**default**: ``https``
|
||||
|
||||
Note that the HTTP server should always use ``https`` with end-user, the ``http`` option
|
||||
is only to be used with an HTTPS proxy.
|
||||
|
||||
``local_only``
|
||||
A boolean value indicating if the gateway is allowed to convert pubsub node from
|
||||
external XMPP service or not. A JID is considered external if its domain part doesn't
|
||||
end with the gateway's server. For instance, if a gateway ``ap.example.org`` is set on
|
||||
the server ``example.org``, the JIDs ``pierre@example.org`` or
|
||||
``some-node@pubsub.example.org`` will be considered local, but
|
||||
``buenaventura@example.net`` won't (note the different domain).
|
||||
|
||||
Most of time, ``local_only`` should be used.
|
||||
|
||||
**default**: ``true``
|
||||
|
||||
``ap_path``
|
||||
Path prefix to use for ActivityPub request. It's usually not necessary to change the
|
||||
default value.
|
||||
|
||||
**default**: ``_ap``
|
||||
|
||||
``comments_max_depth``
|
||||
An integer value indicating the maximum number of comment nodes that can be created. See
|
||||
:ref:`ap-xmpp-threads-conversion`
|
||||
|
||||
``auto_mentions``
|
||||
A boolean value indicating if received XMPP pubsub blog items bodies must be scanned to
|
||||
find ``@user@server.tld`` type mentions. If mentions are found, they'll be added to the
|
||||
resulting AP items.
|
||||
|
||||
**default**: ``true``
|
||||
|
||||
``http_sign_get``
|
||||
A boolean value indicating if HTTP ``GET`` request made to AP implementations must be
|
||||
signed. Some AP implementations require those requests to be signed, notably Mastodon
|
||||
when "secure mode" is activated.
|
||||
|
||||
**default**: ``true``
|
||||
|
||||
``html_redirect_dict``
|
||||
A dictionary used to redirect HTTP requests when it's not an ActivityPub request (i.e.
|
||||
when the ``Accept`` header is not set to ``application/json``). Several ActivityPub
|
||||
implementations link to original server when clicking on some links such as post author
|
||||
or item ID, and this result in a request to the corresponding ActivityPub endpoint, but
|
||||
made to retrieve HTML instead of ActivityPub JSON data.
|
||||
|
||||
By default, this request is showing the corresponding AP JSON data, but if you set HTML
|
||||
redirection, you can redirect the page to your XMPP client web frontend (or anything
|
||||
making sense), which results in better user experience.
|
||||
|
||||
The expected dictionary is a mapping URL request types to destination URL.
|
||||
|
||||
The URL request types is the first path element after ``ap_path``, it can be:
|
||||
|
||||
``actor``
|
||||
Actor information. It should link to the profile page of the corresponding XMPP entity
|
||||
|
||||
``item``
|
||||
A specific publication. It should link to the rendered item
|
||||
|
||||
``followers``
|
||||
Entities publicly subscribed to the actor. It is usually not used for redirection.
|
||||
|
||||
``following``
|
||||
Entities that the actor is publicly subscribed to. It is usually not used for
|
||||
redirection.
|
||||
|
||||
In the target URL you can uses template values in curly braces (something like
|
||||
``{item}``). The values that you can use are:
|
||||
|
||||
``jid``
|
||||
Full JID corresponding to the AP actor.
|
||||
|
||||
``jid_user``
|
||||
Only the user part of the JID (what is before the ``@``)
|
||||
|
||||
``node``
|
||||
Name of the pubsub node corresponding to the AP actor.
|
||||
|
||||
``item``
|
||||
ID of the XMPP pubsub item.
|
||||
|
||||
You can use a slash ``/`` followed by a part of a node name to filter only on specific
|
||||
nodes. For instance, if you want to redirect microblog items to a different URL that
|
||||
event items, you can use ``item/urn:xmpp:microblog:0`` and ``item/urn:xmpp:events:0``,
|
||||
the first redirection to match will be used. Note that anything containing the filter
|
||||
value will match, thus you can also use ``item/microblog`` (but it then would match an
|
||||
event which has ``microblog`` in is node name).
|
||||
|
||||
You can also use a dictionary as value instead of the target URL. This can be useful to
|
||||
filter on an other value than the node name, if you want to make specific redirection
|
||||
for a particular user for instance. If you use a dictionary, you must use a ``url`` key
|
||||
with the target URL (which may have template values as usual), and you may use a
|
||||
``filters`` key mapping to an other dictionary where each key is a filter on a specific
|
||||
template value (in other words: key is the template value, like ``jid`` or ``node``, and
|
||||
value is the filter to match).
|
||||
|
||||
*examples*
|
||||
|
||||
Redirect actor page to ``/profile/<JID user part>``, blogs items to ``/blog/<full
|
||||
JID>/<node name>/<item id>`` and events items to ``/event/<full JID>/<node name>/<item
|
||||
id>`` ::
|
||||
|
||||
html_redirect_dict = {
|
||||
"actor": "/profile/{jid_user}",
|
||||
"item/microblog": "/blog/{jid}/{node}/{item}",
|
||||
"item/events": "/event/{jid}/{node}/{item}"
|
||||
}
|
||||
|
||||
Redirect items of user ``louise@example.org`` to ``/b/<item>``::
|
||||
|
||||
html_redirect_dict = {
|
||||
"item": {
|
||||
"url": "/b/{item}",
|
||||
filters: {
|
||||
"jid": "louise@example.org"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
All options are to be set in ``[components.ap_gateway]`` section.
|
||||
|
||||
.. _ap-actor-from-xmpp:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue