On 08/15/2012 10:20 AM, Alexander Barton wrote:
Am 14.08.2012 um 16:31 schrieb Brett Smith brett@w3.org:
First, users who have passwords with spaces in them can't connect. If I've done my homework right, this seems to be a limitation of the IRC protocol itself: when clients connect, they provide all their important information (nick, username, password, etc.) on a space-separated line, so the server has no choice but to parse a password with spaces as multiple fields. Do I have that right? I'd be happy to be told I'm wrong about this if it means I can accommodate these users better.
No: the PASS command takes one parameter, the syntax is "PASS <password>". But in the IRC protocol, one parameter containing spaces can be passed to the server: you have to prefix it with the ":" character. So the following is completely "legal":
PASS :a nice password
And I don't think that there is a limitation in ngIRCd preventing passwords with spaces from working "per se", but I didn't test …
On the other hand, I easily can imagine that this is a client bug, and the client is sending something line "PASS a nice password" which is … wrong.
Which client are you using?
I was testing with irssi. When I said
/connect irc.example.com 6667 "a nice password"
it would correctly treat the quoted string as one password, but would write it verbatim in the PASS line, so the IRCD sees it as multiple arguments.
Fortunately, at least it's possible to do the right thing by hand:
/connect irc.example.com 6667 ":a nice password"
works as expected.
Would you be willing to consider a patch like this upstream? We'd love to be running stock ngIRCd without any patches, even one as trivial as this.
I'm not sure if "just make the buffer bigger" is the right approach: on the one hand, ngIRCd only needs the password while registering the client in the network, and lots of clients not even send any.
And by looking at the code I wonder why we save the password in the CLIENT structure at all: I don't think that a local daemon ever gets a password from a remote client!?
So I think the best would be to move the password file into the CONN structure, and probably make it dynamic using malloc() when needed …
My boss has given me the green light to spend some time on this, so hopefully I'll have a patch for you soon—later next week, if things go well.
Thanks for all your help.
Best regards,