Open emersion opened 2 years ago
What's the intended use case?
Add a logout button in my client UI.
I mean, why would an end user want to log out?
The original use-case is adding a way for clients to clear credentials on soju. Ref https://todo.sr.ht/~emersion/soju/198
Note, some services support this via a logout
command in NickServ.
<grawity> since SASL reauth is now a thing, I just had a completely stupid idea of reusing `AUTHENTICATE ANONYMOUS` for logging out
I know this may sound a little convoluted but, on an old network I was staff on, the server admin asked that before we detached from our bouncer, we should log out of nickserv and deoper in case your bouncer got compromised. still to this day I have never seen a bouncer get hijacked (maybe someone else has, idk). paranoia use-case I guess.
other use-cases I can think of:
I'm sure there are more use-cases though
These seem to me to be use cases either for a screen lock, or for /QUIT.
In general there seem to be multiple overlapping, but distinct, ideas of what this feature would do:
Bumping because I still think this is a good idea. Deauthing is already a case of doing /msg NickServ logout
, I think the idea to move these already-existing features to a more flush methodology which doesn't require messaging a service bot is a good idea. This motivation already gave birth to account-registration and SASL, albeit they are more for stopping passwords/credentials being sent by PRIVMSG, it still makes sense to continue with moving all of the account-related features to the same realm instead of having the client methodology kept as wildly different throughout those features.
Edit: No IRC didn't think of SASL but it sure as hell implemented it =]
I think a LOGOUT
or DEAUTH
command should be like this:
:client LOGOUT account
to the server providing SASL, requesting for services to log them outAs the popular services packages don't support incoming login information except for during a burst, it's not possible for the server to log the user out and let services know about it.
Note: Race conditions may have an effect here, as something to consider if implementing
What the command does internally is outside of the scope of IRCv3.
What the command does internally is outside of the scope of IRCv3.
Agree. This feels totally ircd-specific. I'm not sure why this is getting tied to SASL. SASL is a mechanism to decouple authentication from the application protocol (here, before the IRC session is finalized). Once everything is registered with IRC, I don't see why this wouldn't be handled a) through the application protocol and b) up to the server to figure out how it wants to handle something like this
before the IRC session is finalized
Nah, SASL can be performed after connection registration too. Even if it wasn't, no reason why one couldn't come up with a pre-registration LOGIN <username> <password>
command.
The reason why SASL is used is to allow for multiple auth mechanisms.
soju now supports AUTHENTICATE ANONYMOUS
as a way to logout.
isn't closing the connection/client/app easier?
Depends if the user wishes to continue interacting with the IRC server after being de-authenticated. Besides, this approach doesn't work with bouncers.
In general there seem to be multiple overlapping, but distinct, ideas of what this feature would do:
- Delete remote credentials (SASL username and password) held by a bouncer
The bouncer already implicitly saves credentials during regular authentication. It's only natural to clear credentials on de-authentication.
I kinda think that we should implement OAUTH2 for IRC.
The
sasl
extension defines theAUTHENTICATE
command to log in (or re-authenticate), but doesn't provide any way to log out.