File

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.

# Groupchat 1.0 usage statistics gathering

Groupchat 1.0 was probably the protocol that predated
[XEP-0045: Multi-User Chat] and there is still some compatibility that
lives on, in the XEP and in implementations.

This module tries to detect clients still using the GC 1.0 protocol and
what software they run, to determine if support can be removed. 

Since joins in the GC 1.0 protocol are highly ambiguous, some hits
reported will be because of desynchronized MUC clients

# Compatibility

Should work with Prosody 0.10.x and earlier.

It will not work with current trunk, since the MUC code has had major
changes.