Closed
Bug 233831
Opened 21 years ago
Closed 20 years ago
CZ should handle 464 numeric
Categories
(Other Applications :: ChatZilla, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: lynX, Assigned: bugzilla-mozilla-20000923)
References
()
Details
(Whiteboard: [cz-0.9.68])
Attachments
(1 file)
3.11 KB,
patch
|
samuel
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•21 years ago
|
||
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.
Assignee | ||
Comment 2•21 years ago
|
||
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
Reporter | ||
Comment 3•21 years ago
|
||
#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!
Assignee | ||
Comment 4•21 years ago
|
||
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.
Reporter | ||
Comment 5•21 years ago
|
||
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.
Assignee | ||
Comment 6•21 years ago
|
||
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?
Reporter | ||
Comment 7•21 years ago
|
||
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
Reporter | ||
Comment 8•21 years ago
|
||
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"); }
Assignee | ||
Comment 9•21 years ago
|
||
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.
Reporter | ||
Comment 10•21 years ago
|
||
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 :)
Assignee | ||
Comment 11•21 years ago
|
||
(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.
Updated•20 years ago
|
Product: Core → Other Applications
Assignee | ||
Comment 12•20 years ago
|
||
No idea if this works, I simply can't test it, but it looks about right.
Comment 13•20 years ago
|
||
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+
Assignee | ||
Comment 14•20 years ago
|
||
Checked in --> FIXED.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•19 years ago
|
Whiteboard: [cz-0.9.68]
You need to log in
before you can comment on or make changes to this bug.
Description
•