PadMessageHandler: Move handleMessage hooks after access check

Move the handleMessageSecurity and handleMessage hooks after the call
to securityManager.checkAccess.

Benefits:

  * A handleMessage plugin can safely assume the message will be
    handled unless the plugin itself drops the message, so it doesn't
    need to repeat the access checks done by the `handleMessage`
    function.
  * This paves the way for a future enhancement: pass the author ID to
    the hooks.

Note: The handleMessageSecurity hook is broken in several ways:

  * The hook result is ignored for `CLIENT_READY` and `SWITCH_TO_PAD`
    messages because the `handleClientReady` function overwrites the
    hook result. This causes the client to receive client vars with
    `readonly` set to true, which causes the client to display an
    immutable pad even though the pad is technically writable.
  * The formatting toolbar buttons are removed for read-only pads
    before the handleMessageSecurity hook even runs.
  * It is awkwardly named: Without reading the documentation, how is
    one supposed to know that "handle message security" actually means
    "grant one-time write access to a read-only pad"?
  * It is called for every message even though calls after a
    `CLIENT_READY` or `SWITCH_TO_PAD` are mostly pointless.
  * Why would anyone want to grant write access when the user visits a
    read-only pad URL? The user should just visit the writable pad URL
    instead.
  * Why would anyone want to grant write access that only lasts for a
    single socket.io connection?
  * There are better ways to temporarily grant write access (e.g., the
    authorize hook).
  * This hook is inviting bugs because it breaks a core assumption
    about `/p/r.*` URLs.

I think the hook should be deprecated and eventually removed.
This commit is contained in:
Richard Hansen 2020-09-10 13:27:59 -04:00 committed by John McLear
parent 0f6baac7b5
commit 1bb44098df
2 changed files with 15 additions and 25 deletions

View file

@ -399,9 +399,6 @@ The handleMessage function must return a Promise. If the Promise resolves to
`null`, the message is dropped. Returning `callback(value)` will return a
Promise that is resolved to `value`.
**WARNING:** handleMessage is called for every message, even if the client is
not authorized to send the message. It is up to the plugin to check permissions.
Examples:
```
@ -444,10 +441,6 @@ The handleMessageSecurity function must return a Promise. If the Promise
resolves to `true`, write access is granted as described above. Returning
`callback(value)` will return a Promise that is resolved to `value`.
**WARNING:** handleMessageSecurity is called for every message, even if the
client is not authorized to send the message. It is up to the plugin to check
permissions.
Examples:
```