Timing of commands/joins sent on network connect

[dgw]

As seen in erming/shout#662, there is a possible issue with using the commands setting on a network to, for example, identify with NickServ before joining channels requiring identification.

Splitting the commands into pre- and post-join sections might be overkill, but there's probably a way to sort this such that commands that the user wants run before joining are, in fact, run before any join commands are sent.

Thoughts?

[xPaw]

I don't think we can guarantee order anyhow.

For nickserv passwords, most servers support putting it in the server password. We also support SASL now, so that's even less of a problem.

[dgw]

This is actually something I struggle with using ZNC, too. It has a tendency to join channels before my vhost is applied.

[maxpoulin64]

The solution indeed is SASL. There's no other way to know for sure if there will be a race condition or not. SASL happens on the registration phase, so it guarantees you're logged in before you even enter the network. This also makes any vhost applied.

@xPaw: I can't find the SASL support. How is it enabled? I looked at both our source and the irc-fw source and can't find how it would be automatically enabled given the parameters we send. Testing also shows SASL isn't attempted. Only the server password forwarding seems to work for now, which is unreliable because it just sends a PRIVMSG behind the scenes and doesn't block the registration process.

@dgw: use the sasl module from ZNC

[dgw]

Not all networks support SASL…

[maxpoulin64]

@dgw: There's also a nickserv ZNC module that actually waits for NickServ to reply before continuing, which works beautifully on that one poorly administrated network that doesn't support SASL.

[dgw]

I use that module, and it does not wait before joining anything. But let's not focus on this one single use case.

[xPaw]

This issue could also possibly be caused by this (which was removed): da425fe#diff-cf27c1d543e886c89cd9ac8b8aeaf05bL245