aatxe / irc

the irc crate – usable, async IRC for Rust
Mozilla Public License 2.0
528 stars 97 forks source link

Allow sending of "raw" messages / allow alternative command formats #128

Closed HeapUnderfl0w closed 6 years ago

HeapUnderfl0w commented 6 years ago

I have the need of sending the PASS and NICK without the leading : in the message, as that hinders me on authenticating correctly.

Best example, attempting to authenticate to the Twitch IRC: With this code:

client.send(format!("PASS {}", oauth_token).as_str()).expect("UNABLE TO SEND AUTH");
client.send(format!("NICK {}", nick).as_str()).expect("UNABLE TO SEND IDENT");

Sends something like this:

PASS :oauth:XXXXXXXXXXXXXXXXX
NICK :somespecificusername

But twitch requires:

PASS oauth:XXXXXXXXXXXXXXXXX
NICK somespecificusername

See the twitch docs for more info

aatxe commented 6 years ago

This is already possible in a way that's a bit more controlled than what you're doing here (just trying to send a string) using Command::Raw.

In this case:

client.send(Command::Raw("PASS".to_owned(), vec![oath_token.to_owned()], None)).unwrap();
client.send(Command::Raw("NICK".to_owned(), vec![nick.to_owned()], None)).unwrap();

For what it's worth, as far as I can tell, this is Twitch failing to comply with the IRC specification, but we could also avoid this by being more conservative about rendering out the leading semicolon (i.e. only doing so using when there's a space in the last argument). I'll think about that bit.

HeapUnderfl0w commented 6 years ago

It seems that that does produces the same output as just using Command::NICK and Command::PASS

For reference, this is the complete code i am using (its derived from the example in the README.md of this repo) https://gist.github.com/HeapUnderfl0w/cbd03bc951d43c27f992f6b3bcdce9ff

If i just look at the traffic, i still get this output:

PASS :oauth:XXXXXXXXXXXXXXXXXXXXX
NICK :heapunderflow

If supporting such is not the target of this crate, please say so (i will attempt to find a different solution)

aatxe commented 6 years ago

Ah, right, this is because of the round-trip through parsing that happens after #80. If I recall correctly, this has been problematic in the past. So, I've pushed the input sanitation later (into the IrcCodec) and so this round trip will no longer happen. I'll be pushing 0.13.5 in a bit which will resolve this issue.

HeapUnderfl0w commented 6 years ago

Ok, feel free to close this issue when you have updated crates.io.

aatxe commented 6 years ago

0.13.5 is published now. 😄