View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0005431unrealircdpublic2019-09-29 16:592020-01-20 15:26
ReporterPeGaSuS Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionno change required 
PlatformUnixOSUbuntuOS Version18.04 LTS
Product Version5.0.0-alpha3 
Summary0005431: [Feature] Add an option to websockets listen block to force a specifc ident to connected users
DescriptionRight now, the ident of a websocket connection is set to the nickname in question
Example: Nick_1!~Nick_1@hostname
Also the ident doesn't respond to set::options::identd-check and therefore is prefixed by a ~
it would be nice if we could specify a specific ident and that would answer successfully to identd requests forced in some way (good for channel bans that use the format *!u@h)
I was thinking in something like:
listen {
    ip *;
    port 1234;
    options {
        websocket {
            type text;
            identd "IDENT";
        };
    };
};

Is this feasible to do?

Cheers
TagsNo tags attached.
3rd party modules

Activities

PeGaSuS

2019-09-29 17:08

reporter   ~0020930

Or probably add that option to a "class websockets".

syzop

2019-12-16 13:25

administrator   ~0021166

Last edited: 2019-12-16 13:26

 You didn't say /why/ you would want this.

Well, you said "right now, the ident of a websocket connection is set to the nickname in question" but that is not true, or at least not what UnrealIRCd is doing. In IRC the username is set to whatever the client requested in the "USER" command during the handshake. It's entirely up to the client to specify this username portion. See https://tools.ietf.org/html/rfc1459#section-4.1.3 If you don't want it to be the nick name, then configure/change the client to specify something else?

I don't think faking an identd when there is no identd is right. I think that would be wrong.

Issue History

Date Modified Username Field Change
2019-09-29 16:59 PeGaSuS New Issue
2019-09-29 17:08 PeGaSuS Note Added: 0020930
2019-12-16 13:25 syzop Note Added: 0021166
2019-12-16 13:26 syzop Note Edited: 0021166
2020-01-20 15:26 syzop Assigned To => syzop
2020-01-20 15:26 syzop Status new => closed
2020-01-20 15:26 syzop Resolution open => no change required