view misc/lnav/prosody.json @ 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 1be6e375a7c2
children
line wrap: on
line source

{
   "$schema" : "https://lnav.org/schemas/format-v1.schema.json",
   "prosody_log" : {
      "body-field" : "message",
      "description" : "The Prosody IM server log format",
      "level" : {
         "debug" : "^debug$",
         "error" : "^error$",
         "info" : "^info$",
         "warning" : "^warn$"
      },
      "level-field" : "loglevel",
      "multiline" : false,
      "ordered-by-time" : true,
      "regex" : {
         "standard" : {
            "pattern" : "^(?<timestamp>\\w{3} \\d{2} \\d{2}:\\d{2}:\\d{2}\\s+)(?<loggername>\\S+)\\s+(?<loglevel>debug|info|warn|error)\\s+(?<message>.+)$"
         }
      },
      "sample" : [
         {
            "line" : "Jan 31 11:07:34 c2s565063fff480\tinfo\tClient connected"
         }
      ],
      "timestamp-field" : "timestamp",
      "timestamp-format" : [
         "%b %d %H:%M:%S "
      ],
      "title" : "Prosody log",
      "url" : "https://prosody.im/doc/logging",
      "value" : {
         "loggername" : {
            "identifier" : true,
            "kind" : "string"
         },
         "payload" : {
            "kind" : "xml"
         }
      }
   }
}