Closed Bug 233831 Opened 21 years ago Closed 20 years ago

CZ should handle 464 numeric

Categories

(Other Applications :: ChatZilla, defect)

x86
All
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lynX, Assigned: bugzilla-mozilla-20000923)

References

()

Details

(Whiteboard: [cz-0.9.68])

Attachments

(1 file)

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Some modern servers request a password on a per-user basis, in that case
it makes no sense to put a "needpass" into the link URL if new users do not
need one. If the person instead uses a registered nickname with a password
the server will correctly transmit something like this:

:ve.symlynX.com 464 * :Please provide your password.

If handled properly I don't see the necessity for a hacky ",needpass" option
for IRC urls - especially since traditional ircds may or may not ask for a
password depending on network topology. So the problem is not specific to
PSYC servers.


Reproducible: Always
Steps to Reproduce:
You can try this out by connecting to irc://ve.symlynX.com using the
nickname "ChatZilla" - I have given it the password "monkey"

Actual Results:  
The message is output and nothing further happens. The problem can
currently be circumvented by typing /pass <pass>.

Expected Results:  
At this point CZ simply needs to open up a prompt(), then send the password
using PASS. No need to reconnect as some broken clients do. A future
version could offer to store passwords using the Mozilla password management.
For testing:

If it is complicated to change your nickname to
"chatzilla" you can register your own nickname on the server
using "+reg <password>", then reconnect and you will be prompted
for that password.
So where is this numeric from? Did someone just make it up because they wanted
this "feature" in an ircd?  (and what's with that malformed URL anyway?)
OS: Linux → All
#define ERR_PASSWDMISMATCH  "464" // Returned to indicate a failed attempt at
                                 // registering a connection for which a
                                 // password was required and was either not
                                 // given or incorrect.

RFC 1459, chapter 6

and concerning the url.. "chatzilla" is intended as a nickname to
*use* for login rather than a nickname to talk to, therefore the
http login syntax would be appropriate also in the irc context.
in fact it should even be capable of carrying the access password,
like this:   irc://ChatZilla:monkey@ve.symlynX.com
i could have left the url field empty, but does that help?

concerning the registration command, since chatzilla is smart
enough to just pass unknown commands to the server you can
simply use /register <password> to register rather than using
the + hack which is only for inflexible irc clients.

btw, have i mentioned i like chatzilla? :)
i'm spreading irc: urls all over my web pages!

kutgw!
The IRC numeric 464 is defined as a reply to the OPER command. I cannot find any
other reference to it in RFC1459.

Do you have any reference for the extended use of numeric 464 by the PSYC ircd?

Also, I should point out that PASS is sent *before* anything else, as per the
spec. Thus the server cannot possibly make any sort of username-password links
at that stage. The ,needpass (and ?pass=) are needed because there is no way to
know if a server needs a password. Handling 464 in the way you describe would
only be an addition, and ,needpass/?pass= would not be redundant at all.

I understood the meaning behind the URL, but it's not (and unlikely to ever be)
a format support by ChatZilla.
That's quite interesting, regular ircds only use 464 for OPER passwords
although in chapter 6 the error is not declared as being limited to that
purpose.

In fact ircII is perfectly capable of handling a 464 during logon process
and will reply with a PASS, not an OPER. Apparently this functionality
was originally intended, then forgotten when the RFC was written. The RFC
only tried to describe current practice of the time. At least I can't
remember it the way it's in the RFC now. Used to be different.

Apparently ircds have evolved into *requiring* the password in advance
which unhappily makes all those "needpass" hacks necessary. Sorry for that.
But maybe future ircds could get user friendlier in that aspect.

The PSYC ircd doesn't use OPER for administrator users, it simply relies
on the password identifications of the users, that's why it can also
accept OPER to deliver the user's password alternatively to PASS.

There is no specific documentation of the PSYC variant of IRC protocol
because there is no variant really. There are no added numerics. MODEs
and other very ircish things are stripped out. Several messages are
output by good old NOTICE. The IRC access is intended to work with any
client and is not the native communication mode for a PSYC server.

There are several added commands which thank to chatzilla's transparent
forwarding are already supported, like the new commands that each
channel defines as it needs, as a replacement to the not so flexible
and instead cryptic MODE.

Forget the irc://logon:pass@server syntax. I don't see much of a
practical use except for debugging or demoing, either.
Ok, withtout and "real" docs, can you explain the criteria this occures in?
Presumably after an incorrect PASS command, what about if you don'y give a PASS
but just go straight in with NICK and USER?
the RFC says.. "and was either not given or incorrect." so for a NICK & USER
whose name is registered the PSYC server will reply with a 464. If the name
is still free the person will immediately be welcomed in.

I just experimented adding a 464 handler to handlers.js, but I suppose the
classic javascript prompt() function will not work here..

CIRCNetwork.prototype.on464 = /* password required, password mismatch */
function my_464 (e)
{
    var newpass = "";
    e.server.parent.display (prompt(e.params[3], [e.params[2], newpass]), "464")
    this.primServ.sendData("PASS " + newpass + "\n");
}
Summary: CZ should handle 464 numeric instead of requiring ,needpass → CZ should handle 464 numeric
now i got it right.. i mean, at least it works for me..
you will probably want to change something about it..
my contribution for your handlers.js:

CIRCNetwork.prototype.on464 = /* password required, password mismatch */
function my_464 (e)
{
    var newpass = "";
    e.server.parent.display (e.params[2], "464");
    newpass = prompt(e.params[2], newpass);
    if (newpass != "") this.primServ.sendData("OPER " + newpass + "\n");
}
I notice you send PASS in the first code snippit, but OPER in the second. I think you said both work with PSYC, but does it matter for other servers? Also, I think we should make sure this dialog doesn't come up if you've joined properly (got to MOTD stage, or something), as it is not normal ChatZilla behaviour to popup dialogs on server messages. I.e. if someone uses OPER on a server that does use it, we I believe we shouldn't have a popup (it's changing existing behaviour, for one thing). Just some random thoughts.
I looked into the ircd source and found that it only sends out 464 when 
/oper is sent without or with a wrong password, or when an operator function 
is requested without prior authentication. So I would presume that prompting 
for a password and delivering it by OPER is an appropriate reaction - as long
as the user has the option of canceling this operation to avoid a deadlock.
The way to input the password should not echo the characters, so it probably
can only be done by a pop up.

I didn't have the impression there *is* any existing behaviour for a 464
type of message, so a simple solution is better than none - for now.

This makes chatzilla a viable alternative for newbie PSYC users which have 
never used IRC before. We have a whole community of people who have used
PSYC as a webchat in the past, they may find chatzilla a more comfortable
interface, but they wouldn't enjoy typing /quote pass <pass> and they
wouldn't figure out that /pass <pass> works, too.

Also, when no IRCNICK is in the environment, would be cool to ask the
person for an initial nickname instead of going for "IRCMonkey". As these
people do have a nickname - but changing identity in PSYC is not as
trivial as typing /NICK. The NICK-change is an optional fun element
within rooms, but the "real" nickname is never changed - it's an identity.
This is very different from IRC where nicknames only give you a hint who
that person may be - and some robot service may help you with that.
But uh.. did I just write a feature request here? At least it's similar.

We have a command that allows to switch identity or connect or a remote
identity on a different server.. /CONNECT.. but it is hardly ever used
and may even be buggy currently. So the two IRC semantics of NICK - fun
masquerading in a room and change of identity - are split into two
commands on PSYC.

Just thoughts.. having any user-friendly 464 handler would be a great start :)
(btw, Bugzilla sucks. that long comment was posted from "links")

Poping up a dialog is not what we do for OPER/other password stuff right now,
and I don't think that's a good change to make (Robert Ginda, thoughts?).
Password popups are bad. :)  I'm only interested in the popup when logging on as
it's what we do currently.

I'm almost tempted to try implementing a non-popup prompt solution...

> I didn't have the impression there *is* any existing behaviour for a 464
> type of message, so a simple solution is better than none - for now.
A simple solution is just to ignore the server's message, and show our own for
the numeric. But I bet you'd rather we didn't do that.

As for IRCMonkey... we *DO* prompt for a nickname when they've not set one.
Product: Core → Other Applications
No idea if this works, I simply can't test it, but it looks about right.
Assignee: rginda → silver
Status: UNCONFIRMED → ASSIGNED
Attachment #172611 - Flags: review?(samuel)
Blocks: 279471
Comment on attachment 172611 [details] [diff] [review]
Handle 464 numeric

I see there's also a msg added in here for 491
Attachment #172611 - Flags: review?(samuel) → review+
Checked in --> FIXED.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: [cz-0.9.68]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: