ircv3-specifications
ircv3-specifications copied to clipboard
ircv3
sasl: make RPL_LOGGEDIN optional on auth success
Bouncers typically have two kind of authentication layers: downstream clients authenticate with the bouncer creedentials, and the bouncer also authenticates against upstream networks.
This causes issues when the bouncer isn't logged in on the upstream network.
When the downstream client authenticates with SASL, they'll get a RPL_LOGGEDIN numeric with the bouncer account name. They'll then hide any login UI.
It would be nicer if RPL_LOGGEDIN/RPL_LOGGEDOUT could be used by bouncers to mirror the status of the upstream connection. So downstream clients would only get RPL_LOGGEDIN if the bouncer is authenticated against the upstream network. That way, clients can show a login UI as needed, and bouncer can forward post-connection-registration AUTHENTICATE commands. Also clients would be able to display "logged in as <network account>" instead of "logged in as <bouncer account>" in their UI.
I'm not sure it is reasonable to make this change now, what if existing clients expect the 903 to proceed? For example, if I understand https://github.com/SrainApp/srain/blob/2234bd9e05e293300db476a9ba687a79efe6f153/src/core/app_irc_event.c#L1747-L1768 correctly, this client uses 900 instead of 903 to decide when to send CAP END. (I know it's wrong, but that's how it is)
Also, nitpick: this is slightly ambiguous, it could imply the 903 is not required if 900 is not sent. I believe you mean: "If authentication is successful, the server MUST send a 903 numeric, which MAY follow a 900 numeric"
Yeah, this might break existing clients. I'm personally fine with implementing this behavior and see how many clients it breaks (ideally sending them patches).
If that helps, I'd be fine adding a new cap for this, too.
mooff said that another option for the bouncer would be to send RPL_LOGGEDIN, and then send RPL_LOGGEDOUT right after. Not as clean, but shouldn't break any client.
Another use-case is when logging in with an account created via draft/account-registration but which hasn't been verified yet. The server can send REGISTER VERIFICATION_REQUIRED instead, and then clients can appropriately show their account verification UI.
@jwheare pointed out that we can't just break the spec. I agree, I'll try to find a better way to move this forward. Maybe we should have sasl-3.3 with this + a few other features like initial response? Does that sound like a good idea? Any other features?
I might be missing some context here, but this (along with the VERIFICATION_REQUIRED problem that was discussed today) sounds like part of a broader class of impedance mismatches created by the bouncer, so it seems like the solution might be to revive the BOUNCER spec and solve them all there?
I don't think the bouncer spec solves any of this. The bouncer spec is just for configuring networks, with my implementation the join channels + SASL details + account registration details aren't part of the network configuration.
FWIW, soju now intentionally breaks the spec and sends RPL_SASLSUCESS without RPL_LOGGEDIN. I haven't found a cleaner way to indicate that SASL suceeded but didn't result in any user login.