mod_client_management: README: Update docs to detail shell and XMPP interfaces

mod_http_oauth2: README: Updated documentation to reflect module status

mod_client_management: Add list-clients + manage-clients permissions to users

mod_client_management: Add support for revoking client access via XMPP

mod_client_management: Improve representation of authentication methods

mod_client_management: Improve table output Requires 1f89a2a9f532 and 1023c3faffac from Prosody.

mod_client_management: Fix user:clients() shell command to take a JID

mod_client_management: Use grant id from key This is a minor tweak - it's faster and preserves compatibility with older data formats (that we don't necessarily want to be compatible with, but some of us have messy data stores and it pays to be a little more robust).

mod_client_management: Fail to revoke clients that have used passwords Return an error so the caller can take appropriate action, e.g. encouraging the user to change their password.

mod_client_management: Add support for revocation of clients (when possible) We decided to keep the unified listing of "clients", which includes both SASL2 clients and OAuth grants, etc. To a user, or someone wanting to manage what can access their account, they are largely equivalent. To accomplish this technically, we add a prefix to the id to state what type it really is.

mod_client_management: Include client type in XML response listing

mod_sasl2_fast: Add API method to revoke FAST tokens for a given client

mod_cloud_notify_filters: Fix traceback when invalid JIDs are submitted

mod_client_management: Add XMPP and shell interfaces to fetch client list

.luacheckrc: Add module.once

mod_audit: Add a command to print the audit log on the command-line

mod_audit: Support for adding location (GeoIP) to audit events This can be more privacy-friendly than logging full IP addresses, and also more informative to a user - IP addresses don't mean much to the average person, however if they see activity from outside their expected country, they can immediately identify suspicious activity. As with IPs, this field is configurable for deployments that would like to disable it. Location is also not logged when the geoip library is not available.

mod_isolate_host: potentially pedantic optimization By Zash.

mod_isolate_host: handle server-generated stanzas The hook for setting the no_host_isolation is only called for c2s sessions. This does not work for stanzas generated by the server, such as PEP notifications or presence probe answers. To handle that, we do per-stanza checks for the case that the origin is local.

mod_authz_delegate: make resistant against startup order issues There is no guarantee that the target_host gets activated and initialized before the host this module is loaded on. As add_default_permission is called during load time by many modules, we need to be prepared to queue stuff.

mod_client_management: New module for users to view/manage permitted clients This is just the data and API part.

mod_http_admin_api: Add roles to user schema in openapi

mod_http_admin_api: Fix types of numbers in openapi spec Numbers are just 'number' in both JSON Schema and Lua

Merge accidental extra head One does not simply rebase public mercurial changesets

mod_vcard_muc: take roles into account for access check This allows admins on the MUC component to force-set avatars, even if they are not owners in a particular MUC, similar to how they are granted auto-ownership in other contexts.

mod_authz_delegate: introduce module to "link" authorization of hosts See the readme :-). Motivation is allowing Snikket admins to change circle avatars via the web portal without bypassing Prosody access checks.

mod_authz_delegate: introduce module to "link" authorization of hosts See the readme :-). Motivation is allowing Snikket admins to change circle avatars via the web portal without bypassing Prosody access checks.

mod_sasl2_fast: Add an API that allows modules to check if a client has FAST

mod_sasl2_fast: Add flag to FAST sasl_handler for easier identification Other code that looks at session.sasl_handler can now detect if a client used FAST to authenticate.

mod_sasl2_fast: Fix harmless off-by-one error (invalidates existing tokens!) Problem: This was causing the key to become "<token>--cur" instead of the expected "<token>-cur". As the same key was used by the code to both set and get, it still worked. Rationale for change: Although it worked, it's unintended, inconsistent and messy. It increases the chances of future bugs due to the unexpected format. Side-effects of change: Existing '--cur' entries will not be checked after this change, and therefore existing FAST clients will fail to authenticate until they attempt password auth and obtain a new FAST token. Existing '--cur' entries in storage will not be cleaned up by this commit, but this is considered a minor issue, and okay for the relatively few FAST deployments.

mod_http_admin_api: Fix missing import Forgot in previous commit

mod_http_admin_api: Tweak token session to please module:may() module:may() checks for type == "c2s", but mod_tokenauth does not currently include that or most common session properties. Fixes a traceback resulting from a different code path where module:may() tries to index event.stanza, which does not exist for http events.

mod_sasl2_fast: Invalidate tokens issued prior to last password change

mod_rest: Add an example bash script for using mod_rest Also supports --login with mod_http_oauth2

mod_http_oauth2: Update to use new API of Prosody mod_tokenauth @ 601d9a375b86

mod_http_oauth2: Add support for refresh tokens

mod_http_oauth2: Declare additional client registration fields as strings Previously any property not listed in the schema was allowed in any form, which is probably a bit too liberal. Instead, limit extra fields to simple strings, which should still allow localized versions of the various URIs and descriptive properties per RFC 7591 §2.2

mod_http_oauth2: Stricten check of urlencoded form data Because type(formdecode("string without equals sign")) == "string", so best avoid continuing in that case, even if strings mostly behave as tables as long as you don't hit one of the __index methods.

mod_http_oauth2: Pedantic optimization Checking the length of the string seems like 30% more expensive than comparing it with the empty string (by reference, probably).

mod_pubsub_feeds: Fix packaging of support library for installer

mod_muc_rtbl: Handle node purge Prevents the module from going out of sync with the node in case this event ever happens.

mod_http_oauth2: Fix traceback on missing 'scope' parameter parse_scopes() takes a string and it is not optional

mod_http_oauth2: Focus username field automatically Reduces effort, not having to click or tab to focus the username field. Should have no negative effects since there's no other elements one might want to focus.

mod_http_oauth2: Allow user to decide which requested scopes to grant These should at the very least be shown to the user, so they can decide whether to grant them. Considered whether to filter the requested scopes down to actually understood scopes that would be granted, but decided that this was a bit complex for a first step, since role role selection and other kinds of scopes are mixed into the same field here.

mod_http_oauth2: Use <fieldset> in templates because it looks nice Removes some CSS as well

mod_rest: Update prosody_oauth.py example to non-legacy OAuth2 Relies on recent mod_http_oauth2 updates

mod_http_oauth2: Remove another reference to obsolete function

mod_http_oauth2: Relax payload content type checking in revocation The code expected Content-Type: application/x-www-form-urlencoded HTTPie sent Content-Type: application/x-www-form-urlencoded; charset=utf-8 It did not work

mod_http_oauth2: Remove now unused code Was apparently only used in revocation which now uses get_request_credentials() directly

mod_http_oauth2: Allow revoking a token without OAuth client credentials If you have a valid token, and you're not supposed to have it, revoking it seems the most responsible thing to do with it, so it should be allowed, while if you are supposed to have it, you should also be allowed to revoke it.

mod_http_oauth2: Correctly verify OAuth client credentials on revocation Makes no sense to validate against username and password here, or using a token to revoke another token, or itself? In fact, upon further discussion, why do you need credentials to revoke a token? If you are not supposed to have the token, revoking it seems the most responsible thing to do with it, so it should be allowed, while if you are supposed to have it, you should be allowed to revoke it.

mod_http_oauth2: Group metadata section into OAuth and OpenID Could easily be confusing otherwise if you're reading one spec and see properties not defined there.

mod_http_oauth2: Rename oauth client credential related functions To make it more explicit what "secret" these deal with.

mod_sasl2: Pull user-agent info into sasl_handler for later reference It may be of interest to post-auth things. Putting it on the session was another option considered, but that seemed unnecessary overhead for something that might be rarely used. sasl_handler is cleared after successful authentication.

mod_adhoc_oauth2_client: Update to call into mod_http_oauth2

mod_http_oauth2: Refactor to allow reuse of OAuth client creation

mod_http_oauth2: Fix userinfo status code off-by-one

mod_http_oauth2: Implement and return ID Token in authorization code flow Is this OIDC?

mod_http_oauth2: Reject non-local hosts in more code paths We're not issuing tokens for users on remote hosts, we can't even authenticate them since they're remote. Thus the host is always the local module.host so no need to pass around the host in most cases or use it for anything but enforcing the same host.

mod_http_oauth2: Add support for the "openid" scope This "openid" scope is there to signal access to the userinfo endpoint, which is needed for OIDC support. We don't actually check this later because the userinfo endpoint only returns info embedded in the token itself, but in the future we may want to check this more carefully.