Connection Registration Question: intended behavior when client sends pass between NICK / USER combo

[mrryanjohnston]

Thank you so much for this valuable resource.

The docs state:

The PASS command is used to set a ‘connection password’. If set, the password must be set before any attempt to register the connection is made. This requires that clients send a PASS command before sending the NICK / USER combination.

What should servers do if they receive a NICK then a PASS before receiving the USER? Technically, the registration is not complete, and the NICK / USER combination have not yet been received. Has the client technically sent the PASS command before sending the NICK / USER combo?

[sadiepowell]

That wording is inherited from RFC 2812 and seems slightly confused. Clients sending PASS between NICK and USER should be discouraged but its not inherently wrong. As a server you should probably accept this unless there's something preventing you from doing so.

[mrryanjohnston]

@SadieCat thanks!

[mrryanjohnston]

I'm happy to make this a separate issue if necessary, but I have another question related to clarifying intended behavior of the server during the registration process.

The PASS message section says:

It is possible to send multiple PASS commands before registering but only the last one sent is used for verification and it may not be changed once the client has been registered

The USER message section does not specify what the server should do when the user sends multiple USER messages before registration is complete. Should the server discard the values sent with the first USER message in favor of the values sent in the second?

[progval]

I think it's fair to leave this as an implementation choice

[mrryanjohnston]

@progval Thanks!

[sadiepowell]

The USER message section does not specify what the server should do when the user sends multiple USER messages before registration is complete. Should the server discard the values sent with the first USER message in favor of the values sent in the second?

The server should probably handle this because the server may respond with an error if the information in the first request isn't valid (e.g. ERR_INVALIDUSERNAME) so it needs to be able to handle the client resending when that happens.

[mrryanjohnston]

@SadieCat It makes sense to me that the server should handle the case where the client sends USER twice if the first message resulted in an ERR_INVALIDUSERNAME. My curiosity was around the case when the first and second USER message was valid.

[mrryanjohnston]

I appreciate the two of you for sating my curiosity so far. I've got another one: is there a "too many arguments" version of ERR_NEEDMOREPARAMS? The behavior I have noticed in other IRC servers is to discard "extra" parameters but not to inform the client.

[progval]

That's correct, extra arguments are always ignored by existing implementations, as far as I know. But also not a requirement for new implementations.

[mrryanjohnston]

@progval thanks. Checking my understanding: If I were to notify the user about the dropped params, I think what I might do is send a WARN as per https://ircv3.net/specs/extensions/standard-replies

It looks like there is only 1 WARN in the registry, and the parameter-related FAIL messages account for INVALID_PARAMS and the previous NEED_MORE_PARAMS. If I understand the spec correctly, I should be able to send back a message that looks like this:

WARN MODE DISCARDED_PARAMS :You sent extra parameters which the server discarded

and the client would display it appropriately. Is my understanding correct?

[progval]

That's correct, just make sure to check for the capability first.

[mrryanjohnston]

@progval Thanks!