Investigate Transparent SASL

[numberoverzero]

From #53, consider an SASL extension or baking functionality into bottom directly.

[numberoverzero]

Looking through these references:

• http://ircv3.net/specs/extensions/sasl-3.1.html
• https://tools.ietf.org/search/rfc4616

I think the plain sasl method could look something like this:

import base64

async def sasl_plain(client, authn_id: str, authz_id: str, password: str):
    pieces = authn_id.encode(), authz_id.encode(), password.encode()
    payload = base64.b64encode(bytes(1).join(pieces))
    client.send_raw(payload.decode())
    # TODO wait for first of 900, 903, 904, 905, 906 using the same pattern
    # as the README's example for waiting on MOTD
    # TODO this will require a new handler that processes 900, 903, 904, 905, 906
    # registered with client.raw_handlers.append(some_handler)

[larsks]

If you're taking requests I vote for this one 😄

[numberoverzero]

Thanks for the comment!

It's been a few years since I added this to the backlog :) I'm happy to take another look though! To help understand what's missing, can you give me a little more information about SASL, and how you want to use it?

• What specific functionality are you looking for?
• Can you provide some pseduocode that show how you'd like to perform SASL authentication?
• Which mechanisms do you use, and can you provide a sample handshake (replacing sensitive material with placeholders)

From looking over the SASL 3.1 and 3.2 extension notes, as well as RFC4616, there's a handful of commands (9xx) that the client needs to know. It's easy enough to craft a login message (see sample above) but waiting on new commands requires a bit more work. A hacked together solution could copy the unpacking code in bottom.client.rfc2812_handler and drop all the params parsing..