view mod_admin_probe/mod_admin_probe.lua @ 5682:527c747711f3

mod_http_oauth2: Limit revocation to clients own tokens in strict mode RFC 7009 section 2.1 states: > The authorization server first validates the client credentials (in > case of a confidential client) and then verifies whether the token was > issued to the client making the revocation request. If this > validation fails, the request is refused and the client is informed of > the error by the authorization server as described below. The first part was already covered (in strict mode). This adds the later part using the hash of client_id recorded in 0860497152af It still seems weird to me that revoking a leaked token should not be allowed whoever might have discovered it, as that seems the responsible thing to do.
author Kim Alvefur <zash@zash.se>
date Sun, 29 Oct 2023 11:30:49 +0100
parents f78661861e98
children
line wrap: on
line source

-- Prosody IM
-- Copyright (C) 2014 Florian Zeitz
--
-- This project is MIT/X11 licensed. Please see the
-- COPYING file in the source package for more information.
--

local presence = module:depends("presence");
local send_presence_of_available_resources = presence.send_presence_of_available_resources;

local hosts = prosody.hosts;
local core_post_stanza = prosody.core_post_stanza;

local st = require "util.stanza";
local is_admin = require "core.usermanager".is_admin;
local jid_split = require "util.jid".split;

module:hook("presence/bare", function(data)
	local origin, stanza = data.origin, data.stanza;
	local to, from, type = stanza.attr.to, stanza.attr.from, stanza.attr.type;
	local node, host = jid_split(to);

	if type ~= "probe" then return; end
	if not is_admin(from, module.host) then return; end

	if 0 == send_presence_of_available_resources(node, host, from, origin) then
		core_post_stanza(hosts[host], st.presence({from=to, to=from, type="unavailable"}), true);
	end
	return true;
end, 10);