realjoshbyrnes / irc2017 Goto Github PK

Passport User with guest nick:
[04:18] * >Liam (7B01C9E89CB6464D467FE1906B754395@GateKeeper) has joined %#The\bLobby [04:18] * >Liam (7B01C9E89CB6464D467FE1906B754395@GateKeeper) Quit (%#The\bLobby)

Guest user with Admin (unicode prefixed) nickname:
[04:19] * 'JD (DEADBEEFDEADBEEFDEADBEEFDEADBEEF@GateKeeper) has joined %#The\bLobby [04:20] * 'JD (DEADBEEFDEADBEEFDEADBEEFDEADBEEF@GateKeeper) Quit (Connection reset by peer)

This was recently discussed in private - that on MSN you could not set a nickname before. Because of backwards compatibility we may need to. Further tests need to be done.

To fix Admin nickname changes ensuring a "'" is prefixed etc

Server should read json settings locally to its own path

show the RealName e.g. the part at end of USER in the WHOIS

When first connecting, typing NICK will allow ANY nickname. (without showing an error message)

If first char of nickname is not '>', it should prepend '>'
Then usual error checking of nickname (for guest) should commence.

If that nickname fails, the error should indicate the ORIGINAL nickname that was specified (param 0)

eg.

-> NICK JD
(server verifies if '>JD' is a valid nickname) - If not:
<- :TK2CHATCHATA01 432 * JD :Erroneous nickname

Restart command would be great for Admins (not Sysops or Guides) to restart the server.

Would require bug #3 to be fixed first.

RegCookie is not implemented

User had no other modes, server sends -q when it shouldn't.

-> TK2CHATCHATA01 MODE %#The\bLobby -o >Skyweb_92994
<- :'L�ам!~Sysop_Cascade@cg MODE %#The\bLobby -q >Skyweb_92994
<- :'L�ам!~Sysop_Cascade@cg MODE %#The\bLobby -o >Skyweb_92994

Is the same if you +o or -o, other modes (-q,+q,+v,-v) seem fine i think, only should be sending -q if the user had owner.

When an admin +v itself and deowner itself the 353 raw becomes ++Nick

Steps to reproduce

JOIN %#The\bLobby
JOIN %#Test
WHOIS NICK

where NICK is in %#The\bLobby but not %#Test

Result: No such nick
Expected: WHOIS REPLY

Kill %#Channelname doesn't kill all the users on a channel, as you can see Sky, Skycrest and Ver|zon were missed out.

-> [NAMES %#The\bLobby]
<- [:TK2CHATCHATA01 353 'Lіам = %#The\bLobby :.'Admin_Sky .'Lіам Demirdjian Skycrest xpu|se Ver|zon >Daisey Sky]
<- [:TK2CHATCHATA01 366 'Lіам %#The\bLobby :End of /NAMES list.]

<- [:Liam!55970E78CACCA30E@GateKeeperPassport JOIN :%#The\bLobby]
-> [KILL %#The\bLobby :Liam test]
<- [:'Lіам!~Sysop_Cascade@cg KILL Demirdjian :Liam test]
<- [:'Lіам!~Sysop_Cascade@cg KILL xpu|se :Liam test]
<- [:'Lіам!~Sysop_Cascade@cg KILL >Daisey :Liam test]
<- [:'Lіам!~Sysop_Cascade@cg KILL Liam :Liam test]

IRCOP should be able to change modes regardless of their current status when on a channel instead of getting

[:TK2CHATCHATA01 482 >Liam %#The\bLobby :You're not channel operator]

As subject

When attempting to add DENY ACCESS to self, it appears that users have no access to their own access list.

if you are in say a channel %#The\bLobby

/whisper %#The\bLobby Nickname :will work

however

/whisper %#the\blobby Nickname:will not work

do to case sensitivity

To implement kills in to webchat

There's a very limited list of which commands should be available to non registered users...
These are the ones I can think of:

AUTH
IRCVERS
MODE (as in MODE ISIRCX or MODE ISIRCX only)
NICK
PASS
PONG (not needed at present, but useful in preventing blind bots)
QUIT
SERVER
USER
WEBIRC

Currently, WHOIS, and possibly other commands are not restricted to registered users only.

You can create a room name with any characters:

primus-ircjs.bundle.js:1 --> CREATE GN %#the�lobby %#the�lobby - EN-US 1 kc31687249d98ae75 0
primus-ircjs.bundle.js:1 <-- :>lol!FF363DB9201CCC42BFD5E1988BB56FF7@GateKeeper JOIN H,U,GO,. :%#the�lobby

At the moment we are giving random nicknames, this should be changed to someone having to set a nickname before joining the chat. Actually the WebChat already compensates for a random nickname.

nvm

Ability to have a Mode event, need to know

Modes will be in raw format

UserMode and ChanMode if differentiated would be great

Ability to set a nickname before connecting

When the Web chat first loads in a freshly opened browser there will be a race condition where the data variable does not exist on the JOIN event. The web chat relies on this in order to work.

Workaround: Hit F5

//mode # +abcdefghijklmnpqrstuvwxyz
produces
Oops! Looks like you've hit a snag here, please can you kindly report this.
while setting some (all?) of the modes yet not showing them

Should be whoever is visible. Yourself. Anyone not -i, anyone on channels you’re on

All clients are seen as connecting from 127.0.0.1.

I can't be sure if this is the gateway or chat server causing this.

Raised by JD and confirmed. If you use Passport and dont prop a USER, and dont use Regcookie you can still get into the server.

The KILL Command is not implemented

When the IRC2017 service is stopped, it does not correctly close/ release the listening socket.

There appears to be a bug that has presented itself during the SSL/IPv6 creation.

All clients are currently marked as 127.0.0.1

When a client is connecting via WSS (WS-Secure), It is expected that the secure flag is set.

Unfortunately, that's not currently the case.

As per title, some properties can be read by opers when they should be write-only.

Current:
<- :TK2CHATCHATA01 432 newnick :Erroneous nickname
Expected:
<- :TK2CHATCHATA01 432 nick newnick :Erroneous nickname

432     ERR_ERRONEUSNICKNAME
                        "<nick> :Erroneus nickname"

                - Returned after receiving a NICK message which contains
                  characters which do not fall in the defined set.  See
                  section x.x.x for details on valid nicknames.

:>JD!54B7627F2F99DBAAC346DCE827619DBB@GateKeeper JOIN H,U,MYO :%#The\bLobby

This issue is caused when a guest sets a profile icon via PROP. It should be disabled for "Guests" and return No permissions to perform command.

--> NICK >Guest_a9b6df97
<-- :>Guest_a9b6df97!~IRCSock@host NICK >Guest_a9b6df97

I'm sure this should be a ERR_NICKNAMEINUSE candidate.

When a quit command arrives, you are simply disconnected.

There is no QUIT or ERROR messages incoming. Literally nothing.
This may cause a few issues:

• Clients may not be aware why they're being disconnected if they have a faulty script
• Clients will usually attempt to automatically reconnect if there's no QUIT or KILL message shown.
• Others?

Kick -
With IRCOP:
-> TK2CHATCHATA01 KICK %#The\bLobby Liam :test
<- :TK2CHATCHATA01 481 'Sysop_Cascade :Permission Denied - You're not an IRC operator

With regular passport:
<- %#The\bLobby; :'Lіам!~Sysop_Cascade@cg MODE %#The\bLobby +o Liam
-> %#The\bLobby; KICK %#The\bLobby Ver|zon :test
<- %#The\bLobby; :TK2CHATCHATA01 481 Liam :Permission Denied - You're not an IRC operator

Kill:
-> TK2CHATCHATA01 KILL %#The\bLobby :Liam
<- :TK2CHATCHATA01 908 'Sysop_Cascade :No permissions to perform command

To fix

When editing the profile the cookies are not re-issued. The Regcookie still holds an obsolete nickname.

Currently when on secure connection member has O in profile instead of B

KILL Nickname - Should kill every instance of that nickname on the server
KILL OID - Should determine whether user/channel and kill appropriately
KILL Channel - Should kill Channel
KILL Channel Nickname - Should only kill user on that channel connection

319 of whois is only showing %#the\blobby when user is actually in multiple chans.