2020-03-13 17:13:03 +00:00
|
|
|
package soju
|
2020-02-06 15:18:19 +00:00
|
|
|
|
|
|
|
import (
|
2020-03-12 20:28:09 +00:00
|
|
|
"crypto/tls"
|
2020-03-16 15:16:27 +00:00
|
|
|
"encoding/base64"
|
2020-02-06 15:18:19 +00:00
|
|
|
"fmt"
|
|
|
|
"io"
|
|
|
|
"net"
|
2020-03-16 14:05:24 +00:00
|
|
|
"strconv"
|
2020-02-07 10:46:44 +00:00
|
|
|
"strings"
|
2020-03-12 20:28:09 +00:00
|
|
|
"time"
|
2020-02-06 15:18:19 +00:00
|
|
|
|
2020-03-16 15:16:27 +00:00
|
|
|
"github.com/emersion/go-sasl"
|
2020-03-11 18:09:32 +00:00
|
|
|
"golang.org/x/crypto/bcrypt"
|
2020-02-06 15:18:19 +00:00
|
|
|
"gopkg.in/irc.v3"
|
|
|
|
)
|
|
|
|
|
|
|
|
type ircError struct {
|
|
|
|
Message *irc.Message
|
|
|
|
}
|
|
|
|
|
2020-03-11 18:09:32 +00:00
|
|
|
func (err ircError) Error() string {
|
|
|
|
return err.Message.String()
|
|
|
|
}
|
|
|
|
|
2020-02-06 15:18:19 +00:00
|
|
|
func newUnknownCommandError(cmd string) ircError {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_UNKNOWNCOMMAND,
|
|
|
|
Params: []string{
|
|
|
|
"*",
|
|
|
|
cmd,
|
|
|
|
"Unknown command",
|
|
|
|
},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
func newNeedMoreParamsError(cmd string) ircError {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NEEDMOREPARAMS,
|
|
|
|
Params: []string{
|
|
|
|
"*",
|
|
|
|
cmd,
|
|
|
|
"Not enough parameters",
|
|
|
|
},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
func newChatHistoryError(subcommand string, target string) ircError {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: "FAIL",
|
|
|
|
Params: []string{"CHATHISTORY", "MESSAGE_ERROR", subcommand, target, "Messages could not be retrieved"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
2020-03-11 18:09:32 +00:00
|
|
|
var errAuthFailed = ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_PASSWDMISMATCH,
|
|
|
|
Params: []string{"*", "Invalid username or password"},
|
|
|
|
}}
|
2020-02-06 15:18:19 +00:00
|
|
|
|
2020-08-25 09:49:22 +00:00
|
|
|
// ' ' and ':' break the IRC message wire format, '@' and '!' break prefixes,
|
|
|
|
// '*' and '?' break masks
|
|
|
|
const illegalNickChars = " :@!*?"
|
2020-08-20 08:00:58 +00:00
|
|
|
|
2020-04-29 17:07:15 +00:00
|
|
|
// permanentDownstreamCaps is the list of always-supported downstream
|
|
|
|
// capabilities.
|
|
|
|
var permanentDownstreamCaps = map[string]string{
|
2021-01-21 08:22:15 +00:00
|
|
|
"batch": "",
|
|
|
|
"cap-notify": "",
|
|
|
|
"echo-message": "",
|
|
|
|
"invite-notify": "",
|
|
|
|
"message-tags": "",
|
|
|
|
"sasl": "PLAIN",
|
|
|
|
"server-time": "",
|
2020-04-29 17:07:15 +00:00
|
|
|
}
|
|
|
|
|
2020-04-30 21:39:59 +00:00
|
|
|
// needAllDownstreamCaps is the list of downstream capabilities that
|
|
|
|
// require support from all upstreams to be enabled
|
|
|
|
var needAllDownstreamCaps = map[string]string{
|
2020-09-08 17:49:06 +00:00
|
|
|
"away-notify": "",
|
|
|
|
"extended-join": "",
|
|
|
|
"multi-prefix": "",
|
2020-04-30 21:39:59 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 22:41:37 +00:00
|
|
|
// passthroughIsupport is the set of ISUPPORT tokens that are directly passed
|
|
|
|
// through from the upstream server to downstream clients.
|
|
|
|
//
|
|
|
|
// This is only effective in single-upstream mode.
|
|
|
|
var passthroughIsupport = map[string]bool{
|
|
|
|
"AWAYLEN": true,
|
|
|
|
"CHANLIMIT": true,
|
|
|
|
"CHANMODES": true,
|
|
|
|
"CHANNELLEN": true,
|
|
|
|
"CHANTYPES": true,
|
|
|
|
"EXCEPTS": true,
|
|
|
|
"EXTBAN": true,
|
|
|
|
"HOSTLEN": true,
|
|
|
|
"INVEX": true,
|
|
|
|
"KICKLEN": true,
|
|
|
|
"MAXLIST": true,
|
|
|
|
"MAXTARGETS": true,
|
|
|
|
"MODES": true,
|
|
|
|
"NETWORK": true,
|
|
|
|
"NICKLEN": true,
|
|
|
|
"PREFIX": true,
|
|
|
|
"SAFELIST": true,
|
|
|
|
"TARGMAX": true,
|
|
|
|
"TOPICLEN": true,
|
|
|
|
"USERLEN": true,
|
|
|
|
}
|
|
|
|
|
2020-02-06 15:18:19 +00:00
|
|
|
type downstreamConn struct {
|
2020-04-03 14:34:11 +00:00
|
|
|
conn
|
|
|
|
|
|
|
|
id uint64
|
2020-02-06 20:11:35 +00:00
|
|
|
|
2020-03-16 08:32:18 +00:00
|
|
|
registered bool
|
|
|
|
user *user
|
|
|
|
nick string
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
nickCM string
|
2020-03-16 08:32:18 +00:00
|
|
|
rawUsername string
|
2020-03-27 18:17:58 +00:00
|
|
|
networkName string
|
2020-03-28 16:25:48 +00:00
|
|
|
clientName string
|
2020-03-16 08:32:18 +00:00
|
|
|
realname string
|
2020-03-21 23:44:55 +00:00
|
|
|
hostname string
|
2020-03-16 08:32:18 +00:00
|
|
|
password string // empty after authentication
|
|
|
|
network *network // can be nil
|
2020-03-16 13:28:45 +00:00
|
|
|
|
2020-03-16 14:05:24 +00:00
|
|
|
negociatingCaps bool
|
|
|
|
capVersion int
|
2020-04-29 17:07:15 +00:00
|
|
|
supportedCaps map[string]string
|
2020-04-06 17:08:43 +00:00
|
|
|
caps map[string]bool
|
2020-03-16 14:05:24 +00:00
|
|
|
|
2020-03-16 15:16:27 +00:00
|
|
|
saslServer sasl.Server
|
2020-02-06 15:18:19 +00:00
|
|
|
}
|
|
|
|
|
2020-07-01 15:02:37 +00:00
|
|
|
func newDownstreamConn(srv *Server, ic ircConn, id uint64) *downstreamConn {
|
|
|
|
remoteAddr := ic.RemoteAddr().String()
|
2020-04-23 20:25:43 +00:00
|
|
|
logger := &prefixLogger{srv.Logger, fmt.Sprintf("downstream %q: ", remoteAddr)}
|
2020-08-19 17:28:29 +00:00
|
|
|
options := connOptions{Logger: logger}
|
2020-02-17 11:36:42 +00:00
|
|
|
dc := &downstreamConn{
|
2020-08-19 17:28:29 +00:00
|
|
|
conn: *newConn(srv, ic, &options),
|
2020-04-29 14:28:33 +00:00
|
|
|
id: id,
|
2020-04-29 17:07:15 +00:00
|
|
|
supportedCaps: make(map[string]string),
|
2020-04-29 14:28:33 +00:00
|
|
|
caps: make(map[string]bool),
|
2020-02-06 20:11:35 +00:00
|
|
|
}
|
2020-04-23 20:25:43 +00:00
|
|
|
dc.hostname = remoteAddr
|
2020-03-21 23:44:55 +00:00
|
|
|
if host, _, err := net.SplitHostPort(dc.hostname); err == nil {
|
|
|
|
dc.hostname = host
|
|
|
|
}
|
2020-04-29 17:07:15 +00:00
|
|
|
for k, v := range permanentDownstreamCaps {
|
|
|
|
dc.supportedCaps[k] = v
|
|
|
|
}
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
if srv.LogPath != "" {
|
|
|
|
dc.supportedCaps["draft/chathistory"] = ""
|
|
|
|
}
|
2020-02-17 11:36:42 +00:00
|
|
|
return dc
|
2020-02-06 20:11:35 +00:00
|
|
|
}
|
|
|
|
|
2020-02-17 11:36:42 +00:00
|
|
|
func (dc *downstreamConn) prefix() *irc.Prefix {
|
2020-02-06 21:19:31 +00:00
|
|
|
return &irc.Prefix{
|
2020-02-17 11:36:42 +00:00
|
|
|
Name: dc.nick,
|
2020-03-28 16:28:28 +00:00
|
|
|
User: dc.user.Username,
|
2020-03-21 23:44:55 +00:00
|
|
|
Host: dc.hostname,
|
2020-02-06 21:19:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-12 18:17:06 +00:00
|
|
|
func (dc *downstreamConn) forEachNetwork(f func(*network)) {
|
|
|
|
if dc.network != nil {
|
|
|
|
f(dc.network)
|
|
|
|
} else {
|
|
|
|
dc.user.forEachNetwork(f)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-04 14:44:13 +00:00
|
|
|
func (dc *downstreamConn) forEachUpstream(f func(*upstreamConn)) {
|
|
|
|
dc.user.forEachUpstream(func(uc *upstreamConn) {
|
2020-03-04 17:22:58 +00:00
|
|
|
if dc.network != nil && uc.network != dc.network {
|
2020-03-04 14:44:13 +00:00
|
|
|
return
|
|
|
|
}
|
|
|
|
f(uc)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2020-03-12 17:33:03 +00:00
|
|
|
// upstream returns the upstream connection, if any. If there are zero or if
|
|
|
|
// there are multiple upstream connections, it returns nil.
|
|
|
|
func (dc *downstreamConn) upstream() *upstreamConn {
|
|
|
|
if dc.network == nil {
|
|
|
|
return nil
|
|
|
|
}
|
2020-04-30 08:25:16 +00:00
|
|
|
return dc.network.conn
|
2020-03-12 17:33:03 +00:00
|
|
|
}
|
|
|
|
|
2020-04-16 15:19:00 +00:00
|
|
|
func isOurNick(net *network, nick string) bool {
|
|
|
|
// TODO: this doesn't account for nick changes
|
|
|
|
if net.conn != nil {
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
return net.casemap(nick) == net.conn.nickCM
|
2020-04-16 15:19:00 +00:00
|
|
|
}
|
|
|
|
// We're not currently connected to the upstream connection, so we don't
|
|
|
|
// know whether this name is our nickname. Best-effort: use the network's
|
|
|
|
// configured nickname and hope it was the one being used when we were
|
|
|
|
// connected.
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
return net.casemap(nick) == net.casemap(net.Nick)
|
2020-04-16 15:19:00 +00:00
|
|
|
}
|
|
|
|
|
2020-04-07 20:30:54 +00:00
|
|
|
// marshalEntity converts an upstream entity name (ie. channel or nick) into a
|
|
|
|
// downstream entity name.
|
|
|
|
//
|
|
|
|
// This involves adding a "/<network>" suffix if the entity isn't the current
|
|
|
|
// user.
|
2020-04-16 15:19:00 +00:00
|
|
|
func (dc *downstreamConn) marshalEntity(net *network, name string) string {
|
2020-05-01 17:03:34 +00:00
|
|
|
if isOurNick(net, name) {
|
|
|
|
return dc.nick
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
name = partialCasemap(net.casemap, name)
|
2020-04-16 14:33:56 +00:00
|
|
|
if dc.network != nil {
|
2020-04-16 15:19:00 +00:00
|
|
|
if dc.network != net {
|
2020-04-16 14:54:13 +00:00
|
|
|
panic("soju: tried to marshal an entity for another network")
|
|
|
|
}
|
2020-04-16 14:33:56 +00:00
|
|
|
return name
|
|
|
|
}
|
2020-04-16 15:19:00 +00:00
|
|
|
return name + "/" + net.GetName()
|
2020-03-18 02:14:36 +00:00
|
|
|
}
|
|
|
|
|
2020-04-16 15:19:00 +00:00
|
|
|
func (dc *downstreamConn) marshalUserPrefix(net *network, prefix *irc.Prefix) *irc.Prefix {
|
|
|
|
if isOurNick(net, prefix.Name) {
|
2020-04-16 14:33:56 +00:00
|
|
|
return dc.prefix()
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
prefix.Name = partialCasemap(net.casemap, prefix.Name)
|
2020-03-20 09:42:17 +00:00
|
|
|
if dc.network != nil {
|
2020-04-16 15:19:00 +00:00
|
|
|
if dc.network != net {
|
2020-04-16 14:54:13 +00:00
|
|
|
panic("soju: tried to marshal a user prefix for another network")
|
|
|
|
}
|
2020-04-16 14:33:56 +00:00
|
|
|
return prefix
|
|
|
|
}
|
|
|
|
return &irc.Prefix{
|
2020-04-16 15:19:00 +00:00
|
|
|
Name: prefix.Name + "/" + net.GetName(),
|
2020-04-16 14:33:56 +00:00
|
|
|
User: prefix.User,
|
|
|
|
Host: prefix.Host,
|
2020-03-18 02:14:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-07 20:30:54 +00:00
|
|
|
// unmarshalEntity converts a downstream entity name (ie. channel or nick) into
|
|
|
|
// an upstream entity name.
|
|
|
|
//
|
|
|
|
// This involves removing the "/<network>" suffix.
|
2020-03-19 23:23:19 +00:00
|
|
|
func (dc *downstreamConn) unmarshalEntity(name string) (*upstreamConn, string, error) {
|
2020-03-12 17:33:03 +00:00
|
|
|
if uc := dc.upstream(); uc != nil {
|
|
|
|
return uc, name, nil
|
|
|
|
}
|
2021-03-16 08:13:46 +00:00
|
|
|
if dc.network != nil {
|
|
|
|
return nil, "", ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NOSUCHCHANNEL,
|
|
|
|
Params: []string{name, "Disconnected from upstream network"},
|
|
|
|
}}
|
|
|
|
}
|
2020-03-12 17:33:03 +00:00
|
|
|
|
2020-03-19 23:23:19 +00:00
|
|
|
var conn *upstreamConn
|
2020-03-18 02:14:36 +00:00
|
|
|
if i := strings.LastIndexByte(name, '/'); i >= 0 {
|
2020-03-19 23:23:19 +00:00
|
|
|
network := name[i+1:]
|
2020-03-18 02:14:36 +00:00
|
|
|
name = name[:i]
|
|
|
|
|
|
|
|
dc.forEachUpstream(func(uc *upstreamConn) {
|
|
|
|
if network != uc.network.GetName() {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
conn = uc
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2020-03-19 23:23:19 +00:00
|
|
|
if conn == nil {
|
2020-03-04 14:44:13 +00:00
|
|
|
return nil, "", ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NOSUCHCHANNEL,
|
2021-03-16 08:13:46 +00:00
|
|
|
Params: []string{name, "Missing network suffix in channel name"},
|
2020-03-04 14:44:13 +00:00
|
|
|
}}
|
2020-02-19 17:25:19 +00:00
|
|
|
}
|
2020-03-19 23:23:19 +00:00
|
|
|
return conn, name, nil
|
2020-02-19 17:25:19 +00:00
|
|
|
}
|
|
|
|
|
2020-04-21 20:54:45 +00:00
|
|
|
func (dc *downstreamConn) unmarshalText(uc *upstreamConn, text string) string {
|
|
|
|
if dc.upstream() != nil {
|
|
|
|
return text
|
|
|
|
}
|
|
|
|
// TODO: smarter parsing that ignores URLs
|
|
|
|
return strings.ReplaceAll(text, "/"+uc.network.GetName(), "")
|
|
|
|
}
|
|
|
|
|
2020-03-27 15:33:19 +00:00
|
|
|
func (dc *downstreamConn) readMessages(ch chan<- event) error {
|
2020-02-06 20:11:35 +00:00
|
|
|
for {
|
2020-04-03 14:34:11 +00:00
|
|
|
msg, err := dc.ReadMessage()
|
2020-02-06 20:11:35 +00:00
|
|
|
if err == io.EOF {
|
|
|
|
break
|
|
|
|
} else if err != nil {
|
|
|
|
return fmt.Errorf("failed to read IRC command: %v", err)
|
|
|
|
}
|
|
|
|
|
2020-03-27 15:33:19 +00:00
|
|
|
ch <- eventDownstreamMessage{msg, dc}
|
2020-02-06 20:11:35 +00:00
|
|
|
}
|
|
|
|
|
2020-02-07 11:42:24 +00:00
|
|
|
return nil
|
2020-02-06 20:11:35 +00:00
|
|
|
}
|
|
|
|
|
2020-04-06 16:23:39 +00:00
|
|
|
// SendMessage sends an outgoing message.
|
|
|
|
//
|
|
|
|
// This can only called from the user goroutine.
|
2020-02-17 11:36:42 +00:00
|
|
|
func (dc *downstreamConn) SendMessage(msg *irc.Message) {
|
2020-04-06 16:23:39 +00:00
|
|
|
if !dc.caps["message-tags"] {
|
2020-05-21 05:04:34 +00:00
|
|
|
if msg.Command == "TAGMSG" {
|
|
|
|
return
|
|
|
|
}
|
2020-04-03 18:48:23 +00:00
|
|
|
msg = msg.Copy()
|
|
|
|
for name := range msg.Tags {
|
|
|
|
supported := false
|
|
|
|
switch name {
|
|
|
|
case "time":
|
2020-04-06 16:23:39 +00:00
|
|
|
supported = dc.caps["server-time"]
|
2020-04-03 18:48:23 +00:00
|
|
|
}
|
|
|
|
if !supported {
|
|
|
|
delete(msg.Tags, name)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-09-08 17:49:06 +00:00
|
|
|
if msg.Command == "JOIN" && !dc.caps["extended-join"] {
|
|
|
|
msg.Params = msg.Params[:1]
|
|
|
|
}
|
2020-04-03 18:48:23 +00:00
|
|
|
|
2020-04-03 14:34:11 +00:00
|
|
|
dc.conn.SendMessage(msg)
|
2020-02-17 11:27:48 +00:00
|
|
|
}
|
|
|
|
|
2020-08-28 15:21:08 +00:00
|
|
|
// sendMessageWithID sends an outgoing message with the specified internal ID.
|
|
|
|
func (dc *downstreamConn) sendMessageWithID(msg *irc.Message, id string) {
|
|
|
|
dc.SendMessage(msg)
|
|
|
|
|
|
|
|
if id == "" || !dc.messageSupportsHistory(msg) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.sendPing(id)
|
|
|
|
}
|
|
|
|
|
|
|
|
// advanceMessageWithID advances history to the specified message ID without
|
|
|
|
// sending a message. This is useful e.g. for self-messages when echo-message
|
|
|
|
// isn't enabled.
|
|
|
|
func (dc *downstreamConn) advanceMessageWithID(msg *irc.Message, id string) {
|
|
|
|
if id == "" || !dc.messageSupportsHistory(msg) {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.sendPing(id)
|
|
|
|
}
|
|
|
|
|
|
|
|
// ackMsgID acknowledges that a message has been received.
|
|
|
|
func (dc *downstreamConn) ackMsgID(id string) {
|
2021-03-31 09:59:13 +00:00
|
|
|
netID, entity, err := parseMsgID(id, nil)
|
2020-08-28 15:21:08 +00:00
|
|
|
if err != nil {
|
|
|
|
dc.logger.Printf("failed to ACK message ID %q: %v", id, err)
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2021-01-04 15:26:30 +00:00
|
|
|
network := dc.user.getNetworkByID(netID)
|
2020-08-28 15:21:08 +00:00
|
|
|
if network == nil {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2021-03-29 15:49:50 +00:00
|
|
|
network.delivered.StoreID(entity, dc.clientName, id)
|
2020-08-28 15:21:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
func (dc *downstreamConn) sendPing(msgID string) {
|
2021-03-31 09:59:13 +00:00
|
|
|
token := "soju-msgid-" + msgID
|
2020-08-28 15:21:08 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Command: "PING",
|
|
|
|
Params: []string{token},
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (dc *downstreamConn) handlePong(token string) {
|
|
|
|
if !strings.HasPrefix(token, "soju-msgid-") {
|
|
|
|
dc.logger.Printf("received unrecognized PONG token %q", token)
|
|
|
|
return
|
|
|
|
}
|
2021-03-31 09:59:13 +00:00
|
|
|
msgID := strings.TrimPrefix(token, "soju-msgid-")
|
2020-08-28 15:21:08 +00:00
|
|
|
dc.ackMsgID(msgID)
|
|
|
|
}
|
|
|
|
|
2020-04-07 17:45:29 +00:00
|
|
|
// marshalMessage re-formats a message coming from an upstream connection so
|
|
|
|
// that it's suitable for being sent on this downstream connection. Only
|
2020-04-30 21:42:33 +00:00
|
|
|
// messages that may appear in logs are supported, except MODE.
|
2020-04-16 15:23:35 +00:00
|
|
|
func (dc *downstreamConn) marshalMessage(msg *irc.Message, net *network) *irc.Message {
|
2020-04-06 15:51:42 +00:00
|
|
|
msg = msg.Copy()
|
2020-04-16 15:23:35 +00:00
|
|
|
msg.Prefix = dc.marshalUserPrefix(net, msg.Prefix)
|
2020-04-07 17:45:29 +00:00
|
|
|
|
2020-04-06 15:51:42 +00:00
|
|
|
switch msg.Command {
|
2020-05-21 05:04:34 +00:00
|
|
|
case "PRIVMSG", "NOTICE", "TAGMSG":
|
2020-04-16 15:23:35 +00:00
|
|
|
msg.Params[0] = dc.marshalEntity(net, msg.Params[0])
|
2020-04-07 17:45:29 +00:00
|
|
|
case "NICK":
|
|
|
|
// Nick change for another user
|
2020-04-16 15:23:35 +00:00
|
|
|
msg.Params[0] = dc.marshalEntity(net, msg.Params[0])
|
2020-04-07 17:45:29 +00:00
|
|
|
case "JOIN", "PART":
|
2020-04-16 15:23:35 +00:00
|
|
|
msg.Params[0] = dc.marshalEntity(net, msg.Params[0])
|
2020-04-07 17:45:29 +00:00
|
|
|
case "KICK":
|
2020-04-16 15:23:35 +00:00
|
|
|
msg.Params[0] = dc.marshalEntity(net, msg.Params[0])
|
|
|
|
msg.Params[1] = dc.marshalEntity(net, msg.Params[1])
|
2020-04-07 17:45:29 +00:00
|
|
|
case "TOPIC":
|
2020-04-16 15:23:35 +00:00
|
|
|
msg.Params[0] = dc.marshalEntity(net, msg.Params[0])
|
2020-04-07 17:45:29 +00:00
|
|
|
case "QUIT":
|
2020-04-16 15:25:39 +00:00
|
|
|
// This space is intentionally left blank
|
2020-04-06 15:51:42 +00:00
|
|
|
default:
|
|
|
|
panic(fmt.Sprintf("unexpected %q message", msg.Command))
|
|
|
|
}
|
|
|
|
|
2020-04-07 17:45:29 +00:00
|
|
|
return msg
|
2020-04-06 15:51:42 +00:00
|
|
|
}
|
|
|
|
|
2020-02-17 11:36:42 +00:00
|
|
|
func (dc *downstreamConn) handleMessage(msg *irc.Message) error {
|
2020-02-06 15:18:19 +00:00
|
|
|
switch msg.Command {
|
2020-02-06 21:22:14 +00:00
|
|
|
case "QUIT":
|
2020-02-17 11:36:42 +00:00
|
|
|
return dc.Close()
|
2020-02-06 15:18:19 +00:00
|
|
|
default:
|
2020-02-17 11:36:42 +00:00
|
|
|
if dc.registered {
|
|
|
|
return dc.handleMessageRegistered(msg)
|
2020-02-06 15:18:19 +00:00
|
|
|
} else {
|
2020-02-17 11:36:42 +00:00
|
|
|
return dc.handleMessageUnregistered(msg)
|
2020-02-06 15:18:19 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-02-17 11:36:42 +00:00
|
|
|
func (dc *downstreamConn) handleMessageUnregistered(msg *irc.Message) error {
|
2020-02-06 15:18:19 +00:00
|
|
|
switch msg.Command {
|
|
|
|
case "NICK":
|
2020-03-18 11:23:08 +00:00
|
|
|
var nick string
|
|
|
|
if err := parseMessageParams(msg, &nick); err != nil {
|
2020-02-07 11:36:02 +00:00
|
|
|
return err
|
2020-02-06 15:18:19 +00:00
|
|
|
}
|
2020-08-20 08:00:58 +00:00
|
|
|
if strings.ContainsAny(nick, illegalNickChars) {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_ERRONEUSNICKNAME,
|
|
|
|
Params: []string{dc.nick, nick, "contains illegal characters"},
|
|
|
|
}}
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
nickCM := casemapASCII(nick)
|
|
|
|
if nickCM == serviceNickCM {
|
2020-03-18 11:23:08 +00:00
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NICKNAMEINUSE,
|
|
|
|
Params: []string{dc.nick, nick, "Nickname reserved for bouncer service"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
dc.nick = nick
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
dc.nickCM = nickCM
|
2020-02-06 15:18:19 +00:00
|
|
|
case "USER":
|
2020-03-18 11:23:08 +00:00
|
|
|
if err := parseMessageParams(msg, &dc.rawUsername, nil, nil, &dc.realname); err != nil {
|
2020-02-07 11:36:02 +00:00
|
|
|
return err
|
2020-02-06 15:18:19 +00:00
|
|
|
}
|
2020-03-11 18:09:32 +00:00
|
|
|
case "PASS":
|
|
|
|
if err := parseMessageParams(msg, &dc.password); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-03-16 14:05:24 +00:00
|
|
|
case "CAP":
|
|
|
|
var subCmd string
|
|
|
|
if err := parseMessageParams(msg, &subCmd); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if err := dc.handleCapCommand(subCmd, msg.Params[1:]); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-03-16 15:16:27 +00:00
|
|
|
case "AUTHENTICATE":
|
2020-04-06 16:23:39 +00:00
|
|
|
if !dc.caps["sasl"] {
|
2020-03-16 15:16:27 +00:00
|
|
|
return ircError{&irc.Message{
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLFAIL,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", "AUTHENTICATE requires the \"sasl\" capability to be enabled"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
if len(msg.Params) == 0 {
|
|
|
|
return ircError{&irc.Message{
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLFAIL,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", "Missing AUTHENTICATE argument"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
if dc.nick == "" {
|
|
|
|
return ircError{&irc.Message{
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLFAIL,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", "Expected NICK command before AUTHENTICATE"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
var resp []byte
|
|
|
|
if dc.saslServer == nil {
|
|
|
|
mech := strings.ToUpper(msg.Params[0])
|
|
|
|
switch mech {
|
|
|
|
case "PLAIN":
|
|
|
|
dc.saslServer = sasl.NewPlainServer(sasl.PlainAuthenticator(func(identity, username, password string) error {
|
|
|
|
return dc.authenticate(username, password)
|
|
|
|
}))
|
|
|
|
default:
|
|
|
|
return ircError{&irc.Message{
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLFAIL,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", fmt.Sprintf("Unsupported SASL mechanism %q", mech)},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
} else if msg.Params[0] == "*" {
|
|
|
|
dc.saslServer = nil
|
|
|
|
return ircError{&irc.Message{
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLABORTED,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", "SASL authentication aborted"},
|
|
|
|
}}
|
|
|
|
} else if msg.Params[0] == "+" {
|
|
|
|
resp = nil
|
|
|
|
} else {
|
|
|
|
// TODO: multi-line messages
|
|
|
|
var err error
|
|
|
|
resp, err = base64.StdEncoding.DecodeString(msg.Params[0])
|
|
|
|
if err != nil {
|
|
|
|
dc.saslServer = nil
|
|
|
|
return ircError{&irc.Message{
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLFAIL,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", "Invalid base64-encoded response"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
challenge, done, err := dc.saslServer.Next(resp)
|
|
|
|
if err != nil {
|
|
|
|
dc.saslServer = nil
|
|
|
|
if ircErr, ok := err.(ircError); ok && ircErr.Message.Command == irc.ERR_PASSWDMISMATCH {
|
|
|
|
return ircError{&irc.Message{
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLFAIL,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", ircErr.Message.Params[1]},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.ERR_SASLFAIL,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{"*", "SASL error"},
|
|
|
|
})
|
|
|
|
return fmt.Errorf("SASL authentication failed: %v", err)
|
|
|
|
} else if done {
|
|
|
|
dc.saslServer = nil
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.RPL_LOGGEDIN,
|
2020-06-01 12:41:47 +00:00
|
|
|
Params: []string{dc.nick, dc.prefix().String(), dc.user.Username, "You are now logged in"},
|
2020-03-16 15:16:27 +00:00
|
|
|
})
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-03-19 13:51:45 +00:00
|
|
|
Command: irc.RPL_SASLSUCCESS,
|
2020-03-16 15:16:27 +00:00
|
|
|
Params: []string{dc.nick, "SASL authentication successful"},
|
|
|
|
})
|
|
|
|
} else {
|
|
|
|
challengeStr := "+"
|
2020-03-21 07:44:03 +00:00
|
|
|
if len(challenge) > 0 {
|
2020-03-16 15:16:27 +00:00
|
|
|
challengeStr = base64.StdEncoding.EncodeToString(challenge)
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: multi-line messages
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "AUTHENTICATE",
|
|
|
|
Params: []string{challengeStr},
|
|
|
|
})
|
|
|
|
}
|
2020-02-06 15:18:19 +00:00
|
|
|
default:
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.logger.Printf("unhandled message: %v", msg)
|
2020-02-06 15:18:19 +00:00
|
|
|
return newUnknownCommandError(msg.Command)
|
|
|
|
}
|
2020-03-16 14:05:24 +00:00
|
|
|
if dc.rawUsername != "" && dc.nick != "" && !dc.negociatingCaps {
|
2020-02-17 11:36:42 +00:00
|
|
|
return dc.register()
|
2020-02-06 15:18:19 +00:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-03-16 14:05:24 +00:00
|
|
|
func (dc *downstreamConn) handleCapCommand(cmd string, args []string) error {
|
2020-03-16 14:11:08 +00:00
|
|
|
cmd = strings.ToUpper(cmd)
|
|
|
|
|
2020-03-16 14:05:24 +00:00
|
|
|
replyTo := dc.nick
|
|
|
|
if !dc.registered {
|
|
|
|
replyTo = "*"
|
|
|
|
}
|
|
|
|
|
|
|
|
switch cmd {
|
|
|
|
case "LS":
|
|
|
|
if len(args) > 0 {
|
|
|
|
var err error
|
|
|
|
if dc.capVersion, err = strconv.Atoi(args[0]); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
2020-11-26 14:41:18 +00:00
|
|
|
if !dc.registered && dc.capVersion >= 302 {
|
|
|
|
// Let downstream show everything it supports, and trim
|
|
|
|
// down the available capabilities when upstreams are
|
|
|
|
// known.
|
|
|
|
for k, v := range needAllDownstreamCaps {
|
|
|
|
dc.supportedCaps[k] = v
|
|
|
|
}
|
|
|
|
}
|
2020-03-16 14:05:24 +00:00
|
|
|
|
2020-04-29 17:07:15 +00:00
|
|
|
caps := make([]string, 0, len(dc.supportedCaps))
|
|
|
|
for k, v := range dc.supportedCaps {
|
|
|
|
if dc.capVersion >= 302 && v != "" {
|
2020-04-29 14:28:33 +00:00
|
|
|
caps = append(caps, k+"="+v)
|
2020-04-29 17:07:15 +00:00
|
|
|
} else {
|
|
|
|
caps = append(caps, k)
|
|
|
|
}
|
2020-03-16 15:16:27 +00:00
|
|
|
}
|
2020-03-16 14:05:24 +00:00
|
|
|
|
|
|
|
// TODO: multi-line replies
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "CAP",
|
|
|
|
Params: []string{replyTo, "LS", strings.Join(caps, " ")},
|
|
|
|
})
|
|
|
|
|
2020-04-29 17:07:15 +00:00
|
|
|
if dc.capVersion >= 302 {
|
|
|
|
// CAP version 302 implicitly enables cap-notify
|
|
|
|
dc.caps["cap-notify"] = true
|
|
|
|
}
|
|
|
|
|
2020-03-16 14:05:24 +00:00
|
|
|
if !dc.registered {
|
|
|
|
dc.negociatingCaps = true
|
|
|
|
}
|
|
|
|
case "LIST":
|
|
|
|
var caps []string
|
|
|
|
for name := range dc.caps {
|
|
|
|
caps = append(caps, name)
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: multi-line replies
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "CAP",
|
|
|
|
Params: []string{replyTo, "LIST", strings.Join(caps, " ")},
|
|
|
|
})
|
|
|
|
case "REQ":
|
|
|
|
if len(args) == 0 {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: err_invalidcapcmd,
|
|
|
|
Params: []string{replyTo, cmd, "Missing argument in CAP REQ command"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
2020-04-29 17:07:15 +00:00
|
|
|
// TODO: atomically ack/nak the whole capability set
|
2020-03-16 14:05:24 +00:00
|
|
|
caps := strings.Fields(args[0])
|
|
|
|
ack := true
|
|
|
|
for _, name := range caps {
|
|
|
|
name = strings.ToLower(name)
|
|
|
|
enable := !strings.HasPrefix(name, "-")
|
|
|
|
if !enable {
|
|
|
|
name = strings.TrimPrefix(name, "-")
|
|
|
|
}
|
|
|
|
|
2020-04-29 17:07:15 +00:00
|
|
|
if enable == dc.caps[name] {
|
2020-03-16 14:05:24 +00:00
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2020-04-29 17:07:15 +00:00
|
|
|
_, ok := dc.supportedCaps[name]
|
|
|
|
if !ok {
|
|
|
|
ack = false
|
|
|
|
break
|
|
|
|
}
|
|
|
|
|
|
|
|
if name == "cap-notify" && dc.capVersion >= 302 && !enable {
|
|
|
|
// cap-notify cannot be disabled with CAP version 302
|
2020-03-16 14:05:24 +00:00
|
|
|
ack = false
|
2020-04-29 17:07:15 +00:00
|
|
|
break
|
2020-03-16 14:05:24 +00:00
|
|
|
}
|
2020-04-29 17:07:15 +00:00
|
|
|
|
|
|
|
dc.caps[name] = enable
|
2020-03-16 14:05:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
reply := "NAK"
|
|
|
|
if ack {
|
|
|
|
reply = "ACK"
|
|
|
|
}
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "CAP",
|
|
|
|
Params: []string{replyTo, reply, args[0]},
|
|
|
|
})
|
|
|
|
case "END":
|
|
|
|
dc.negociatingCaps = false
|
|
|
|
default:
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: err_invalidcapcmd,
|
|
|
|
Params: []string{replyTo, cmd, "Unknown CAP command"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-04-29 17:07:15 +00:00
|
|
|
func (dc *downstreamConn) setSupportedCap(name, value string) {
|
|
|
|
prevValue, hasPrev := dc.supportedCaps[name]
|
|
|
|
changed := !hasPrev || prevValue != value
|
|
|
|
dc.supportedCaps[name] = value
|
|
|
|
|
|
|
|
if !dc.caps["cap-notify"] || !changed {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
replyTo := dc.nick
|
|
|
|
if !dc.registered {
|
|
|
|
replyTo = "*"
|
|
|
|
}
|
|
|
|
|
|
|
|
cap := name
|
|
|
|
if value != "" && dc.capVersion >= 302 {
|
|
|
|
cap = name + "=" + value
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "CAP",
|
|
|
|
Params: []string{replyTo, "NEW", cap},
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
func (dc *downstreamConn) unsetSupportedCap(name string) {
|
|
|
|
_, hasPrev := dc.supportedCaps[name]
|
|
|
|
delete(dc.supportedCaps, name)
|
|
|
|
delete(dc.caps, name)
|
|
|
|
|
|
|
|
if !dc.caps["cap-notify"] || !hasPrev {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
replyTo := dc.nick
|
|
|
|
if !dc.registered {
|
|
|
|
replyTo = "*"
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "CAP",
|
|
|
|
Params: []string{replyTo, "DEL", name},
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2020-04-29 14:28:33 +00:00
|
|
|
func (dc *downstreamConn) updateSupportedCaps() {
|
2020-04-30 21:39:59 +00:00
|
|
|
supportedCaps := make(map[string]bool)
|
|
|
|
for cap := range needAllDownstreamCaps {
|
|
|
|
supportedCaps[cap] = true
|
|
|
|
}
|
2020-04-29 14:28:33 +00:00
|
|
|
dc.forEachUpstream(func(uc *upstreamConn) {
|
2020-04-30 21:39:59 +00:00
|
|
|
for cap, supported := range supportedCaps {
|
|
|
|
supportedCaps[cap] = supported && uc.caps[cap]
|
|
|
|
}
|
2020-04-29 14:28:33 +00:00
|
|
|
})
|
|
|
|
|
2020-04-30 21:39:59 +00:00
|
|
|
for cap, supported := range supportedCaps {
|
|
|
|
if supported {
|
|
|
|
dc.setSupportedCap(cap, needAllDownstreamCaps[cap])
|
|
|
|
} else {
|
|
|
|
dc.unsetSupportedCap(cap)
|
|
|
|
}
|
2020-04-29 14:28:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-30 22:37:42 +00:00
|
|
|
func (dc *downstreamConn) updateNick() {
|
|
|
|
if uc := dc.upstream(); uc != nil && uc.nick != dc.nick {
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.prefix(),
|
|
|
|
Command: "NICK",
|
|
|
|
Params: []string{uc.nick},
|
|
|
|
})
|
|
|
|
dc.nick = uc.nick
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
dc.nickCM = casemapASCII(dc.nick)
|
2020-04-30 22:37:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-12 20:28:09 +00:00
|
|
|
func sanityCheckServer(addr string) error {
|
|
|
|
dialer := net.Dialer{Timeout: 30 * time.Second}
|
|
|
|
conn, err := tls.DialWithDialer(&dialer, "tcp", addr, nil)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
return conn.Close()
|
|
|
|
}
|
|
|
|
|
2020-03-28 16:25:48 +00:00
|
|
|
func unmarshalUsername(rawUsername string) (username, client, network string) {
|
2020-03-16 15:16:27 +00:00
|
|
|
username = rawUsername
|
2020-03-28 16:25:48 +00:00
|
|
|
|
|
|
|
i := strings.IndexAny(username, "/@")
|
|
|
|
j := strings.LastIndexAny(username, "/@")
|
|
|
|
if i >= 0 {
|
|
|
|
username = rawUsername[:i]
|
|
|
|
}
|
|
|
|
if j >= 0 {
|
2020-03-31 17:02:02 +00:00
|
|
|
if rawUsername[j] == '@' {
|
|
|
|
client = rawUsername[j+1:]
|
|
|
|
} else {
|
|
|
|
network = rawUsername[j+1:]
|
|
|
|
}
|
2020-03-04 14:44:13 +00:00
|
|
|
}
|
2020-03-28 16:25:48 +00:00
|
|
|
if i >= 0 && j >= 0 && i < j {
|
2020-03-31 17:02:02 +00:00
|
|
|
if rawUsername[i] == '@' {
|
|
|
|
client = rawUsername[i+1 : j]
|
|
|
|
} else {
|
|
|
|
network = rawUsername[i+1 : j]
|
|
|
|
}
|
2020-03-04 14:44:13 +00:00
|
|
|
}
|
2020-03-28 16:25:48 +00:00
|
|
|
|
|
|
|
return username, client, network
|
2020-03-16 15:16:27 +00:00
|
|
|
}
|
2020-03-04 14:44:13 +00:00
|
|
|
|
2020-03-27 18:17:58 +00:00
|
|
|
func (dc *downstreamConn) authenticate(username, password string) error {
|
2020-03-28 16:25:48 +00:00
|
|
|
username, clientName, networkName := unmarshalUsername(username)
|
2020-03-27 18:17:58 +00:00
|
|
|
|
2020-03-27 21:38:38 +00:00
|
|
|
u, err := dc.srv.db.GetUser(username)
|
|
|
|
if err != nil {
|
2020-11-25 12:40:55 +00:00
|
|
|
dc.logger.Printf("failed authentication for %q: user not found: %v", username, err)
|
2020-03-27 18:17:58 +00:00
|
|
|
return errAuthFailed
|
|
|
|
}
|
|
|
|
|
2020-06-06 10:52:22 +00:00
|
|
|
// Password auth disabled
|
|
|
|
if u.Password == "" {
|
|
|
|
return errAuthFailed
|
|
|
|
}
|
|
|
|
|
2020-03-27 21:38:38 +00:00
|
|
|
err = bcrypt.CompareHashAndPassword([]byte(u.Password), []byte(password))
|
2020-03-27 18:17:58 +00:00
|
|
|
if err != nil {
|
2020-11-25 12:40:55 +00:00
|
|
|
dc.logger.Printf("failed authentication for %q: wrong password: %v", username, err)
|
2020-03-27 18:17:58 +00:00
|
|
|
return errAuthFailed
|
|
|
|
}
|
|
|
|
|
2020-03-27 21:38:38 +00:00
|
|
|
dc.user = dc.srv.getUser(username)
|
|
|
|
if dc.user == nil {
|
|
|
|
dc.logger.Printf("failed authentication for %q: user not active", username)
|
|
|
|
return errAuthFailed
|
|
|
|
}
|
2020-03-28 16:25:48 +00:00
|
|
|
dc.clientName = clientName
|
2020-03-27 18:17:58 +00:00
|
|
|
dc.networkName = networkName
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (dc *downstreamConn) register() error {
|
|
|
|
if dc.registered {
|
|
|
|
return fmt.Errorf("tried to register twice")
|
|
|
|
}
|
|
|
|
|
|
|
|
password := dc.password
|
|
|
|
dc.password = ""
|
|
|
|
if dc.user == nil {
|
|
|
|
if err := dc.authenticate(dc.rawUsername, password); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-28 16:25:48 +00:00
|
|
|
if dc.clientName == "" && dc.networkName == "" {
|
|
|
|
_, dc.clientName, dc.networkName = unmarshalUsername(dc.rawUsername)
|
2020-03-27 18:17:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
dc.registered = true
|
2020-03-28 16:28:28 +00:00
|
|
|
dc.logger.Printf("registration complete for user %q", dc.user.Username)
|
2020-03-27 18:17:58 +00:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (dc *downstreamConn) loadNetwork() error {
|
|
|
|
if dc.networkName == "" {
|
2020-03-16 15:16:27 +00:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-03-27 18:17:58 +00:00
|
|
|
network := dc.user.getNetwork(dc.networkName)
|
2020-03-16 15:16:27 +00:00
|
|
|
if network == nil {
|
2020-03-27 18:17:58 +00:00
|
|
|
addr := dc.networkName
|
2020-03-16 15:16:27 +00:00
|
|
|
if !strings.ContainsRune(addr, ':') {
|
|
|
|
addr = addr + ":6697"
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.logger.Printf("trying to connect to new network %q", addr)
|
|
|
|
if err := sanityCheckServer(addr); err != nil {
|
|
|
|
dc.logger.Printf("failed to connect to %q: %v", addr, err)
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_PASSWDMISMATCH,
|
2020-03-27 18:17:58 +00:00
|
|
|
Params: []string{"*", fmt.Sprintf("Failed to connect to %q", dc.networkName)},
|
2020-03-16 15:16:27 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
2020-07-06 16:13:40 +00:00
|
|
|
// Some clients only allow specifying the nickname (and use the
|
|
|
|
// nickname as a username too). Strip the network name from the
|
|
|
|
// nickname when auto-saving networks.
|
|
|
|
nick, _, _ := unmarshalUsername(dc.nick)
|
|
|
|
|
2020-03-27 18:17:58 +00:00
|
|
|
dc.logger.Printf("auto-saving network %q", dc.networkName)
|
2020-03-16 15:16:27 +00:00
|
|
|
var err error
|
2020-03-18 23:57:14 +00:00
|
|
|
network, err = dc.user.createNetwork(&Network{
|
2020-03-27 18:17:58 +00:00
|
|
|
Addr: dc.networkName,
|
2020-07-06 16:13:40 +00:00
|
|
|
Nick: nick,
|
2020-03-18 23:57:14 +00:00
|
|
|
})
|
2020-03-16 15:16:27 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.network = network
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-03-27 18:17:58 +00:00
|
|
|
func (dc *downstreamConn) welcome() error {
|
|
|
|
if dc.user == nil || !dc.registered {
|
|
|
|
panic("tried to welcome an unregistered connection")
|
2020-02-07 10:36:42 +00:00
|
|
|
}
|
|
|
|
|
2020-03-27 18:17:58 +00:00
|
|
|
// TODO: doing this might take some time. We should do it in dc.register
|
|
|
|
// instead, but we'll potentially be adding a new network and this must be
|
|
|
|
// done in the user goroutine.
|
|
|
|
if err := dc.loadNetwork(); err != nil {
|
|
|
|
return err
|
2020-03-04 14:44:13 +00:00
|
|
|
}
|
|
|
|
|
2021-01-22 10:55:06 +00:00
|
|
|
isupport := []string{
|
|
|
|
fmt.Sprintf("CHATHISTORY=%v", dc.srv.HistoryLimit),
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
"CASEMAPPING=ascii",
|
2021-01-22 10:55:06 +00:00
|
|
|
}
|
|
|
|
|
2021-03-15 22:41:37 +00:00
|
|
|
if uc := dc.upstream(); uc != nil {
|
|
|
|
for k := range passthroughIsupport {
|
|
|
|
v, ok := uc.isupport[k]
|
|
|
|
if !ok {
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
if v != nil {
|
|
|
|
isupport = append(isupport, fmt.Sprintf("%v=%v", k, *v))
|
|
|
|
} else {
|
|
|
|
isupport = append(isupport, k)
|
|
|
|
}
|
|
|
|
}
|
2021-01-22 11:00:02 +00:00
|
|
|
}
|
|
|
|
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-02-06 15:18:19 +00:00
|
|
|
Command: irc.RPL_WELCOME,
|
2020-03-13 17:13:03 +00:00
|
|
|
Params: []string{dc.nick, "Welcome to soju, " + dc.nick},
|
2020-02-17 11:27:48 +00:00
|
|
|
})
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-02-06 15:18:19 +00:00
|
|
|
Command: irc.RPL_YOURHOST,
|
2020-02-17 11:36:42 +00:00
|
|
|
Params: []string{dc.nick, "Your host is " + dc.srv.Hostname},
|
2020-02-17 11:27:48 +00:00
|
|
|
})
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-02-06 15:18:19 +00:00
|
|
|
Command: irc.RPL_CREATED,
|
2020-02-17 11:36:42 +00:00
|
|
|
Params: []string{dc.nick, "Who cares when the server was created?"},
|
2020-02-17 11:27:48 +00:00
|
|
|
})
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-02-06 15:18:19 +00:00
|
|
|
Command: irc.RPL_MYINFO,
|
2020-03-13 17:13:03 +00:00
|
|
|
Params: []string{dc.nick, dc.srv.Hostname, "soju", "aiwroO", "OovaimnqpsrtklbeI"},
|
2020-02-17 11:27:48 +00:00
|
|
|
})
|
2021-03-15 22:41:37 +00:00
|
|
|
for _, msg := range generateIsupport(dc.srv.prefix(), dc.nick, isupport) {
|
|
|
|
dc.SendMessage(msg)
|
|
|
|
}
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-02-06 15:18:19 +00:00
|
|
|
Command: irc.ERR_NOMOTD,
|
2020-02-17 11:36:42 +00:00
|
|
|
Params: []string{dc.nick, "No MOTD"},
|
2020-02-17 11:27:48 +00:00
|
|
|
})
|
2020-02-06 15:18:19 +00:00
|
|
|
|
2020-04-30 22:37:42 +00:00
|
|
|
dc.updateNick()
|
2020-11-26 14:41:18 +00:00
|
|
|
dc.updateSupportedCaps()
|
2020-04-30 22:37:42 +00:00
|
|
|
|
2020-03-04 14:44:13 +00:00
|
|
|
dc.forEachUpstream(func(uc *upstreamConn) {
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
for _, entry := range uc.channels.innerMap {
|
|
|
|
ch := entry.value.(*upstreamChannel)
|
2020-04-28 13:27:41 +00:00
|
|
|
if !ch.complete {
|
|
|
|
continue
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
record := uc.network.channels.Value(ch.Name)
|
|
|
|
if record != nil && record.Detached {
|
2020-04-28 13:27:41 +00:00
|
|
|
continue
|
2020-02-06 21:29:24 +00:00
|
|
|
}
|
2020-04-28 13:27:41 +00:00
|
|
|
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.prefix(),
|
|
|
|
Command: "JOIN",
|
|
|
|
Params: []string{dc.marshalEntity(ch.conn.network, ch.Name)},
|
|
|
|
})
|
|
|
|
|
|
|
|
forwardChannel(dc, ch)
|
2020-02-06 21:29:24 +00:00
|
|
|
}
|
2020-03-25 09:53:08 +00:00
|
|
|
})
|
2020-02-07 15:43:14 +00:00
|
|
|
|
2020-03-25 09:53:08 +00:00
|
|
|
dc.forEachNetwork(func(net *network) {
|
2020-04-10 17:22:47 +00:00
|
|
|
// Only send history if we're the first connected client with that name
|
|
|
|
// for the network
|
2021-03-29 14:55:57 +00:00
|
|
|
firstClient := true
|
|
|
|
dc.user.forEachDownstream(func(c *downstreamConn) {
|
|
|
|
if c != dc && c.clientName == dc.clientName && c.network == dc.network {
|
|
|
|
firstClient = false
|
|
|
|
}
|
|
|
|
})
|
|
|
|
if firstClient {
|
2021-03-29 15:49:50 +00:00
|
|
|
net.delivered.ForEachTarget(func(target string) {
|
|
|
|
dc.sendTargetBacklog(net, target)
|
|
|
|
})
|
2020-04-10 17:22:47 +00:00
|
|
|
}
|
2020-08-19 11:24:05 +00:00
|
|
|
|
|
|
|
// Fast-forward history to last message
|
2021-03-29 15:49:50 +00:00
|
|
|
net.delivered.ForEachTarget(func(target string) {
|
|
|
|
ch := net.channels.Value(target)
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
if ch != nil && ch.Detached {
|
2021-03-29 15:49:50 +00:00
|
|
|
return
|
2020-08-19 11:24:05 +00:00
|
|
|
}
|
|
|
|
|
2021-03-29 15:49:50 +00:00
|
|
|
targetCM := net.casemap(target)
|
2021-03-29 15:07:39 +00:00
|
|
|
lastID, err := dc.user.msgStore.LastMsgID(net, targetCM, time.Now())
|
2020-08-19 11:24:05 +00:00
|
|
|
if err != nil {
|
|
|
|
dc.logger.Printf("failed to get last message ID: %v", err)
|
2021-03-29 15:49:50 +00:00
|
|
|
return
|
2020-08-19 11:24:05 +00:00
|
|
|
}
|
2021-03-29 15:49:50 +00:00
|
|
|
|
|
|
|
net.delivered.StoreID(target, dc.clientName, lastID)
|
|
|
|
})
|
2020-04-10 17:22:47 +00:00
|
|
|
})
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-08-28 15:21:08 +00:00
|
|
|
// messageSupportsHistory checks whether the provided message can be sent as
|
|
|
|
// part of an history batch.
|
|
|
|
func (dc *downstreamConn) messageSupportsHistory(msg *irc.Message) bool {
|
|
|
|
// Don't replay all messages, because that would mess up client
|
|
|
|
// state. For instance we just sent the list of users, sending
|
|
|
|
// PART messages for one of these users would be incorrect.
|
|
|
|
// TODO: add support for draft/event-playback
|
|
|
|
switch msg.Command {
|
|
|
|
case "PRIVMSG", "NOTICE":
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
return false
|
|
|
|
}
|
|
|
|
|
2021-02-10 12:48:41 +00:00
|
|
|
func (dc *downstreamConn) sendTargetBacklog(net *network, target string) {
|
2020-10-25 10:13:51 +00:00
|
|
|
if dc.caps["draft/chathistory"] || dc.user.msgStore == nil {
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
return
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
if ch := net.channels.Value(target); ch != nil && ch.Detached {
|
2021-02-10 12:48:41 +00:00
|
|
|
return
|
|
|
|
}
|
2021-03-29 15:49:50 +00:00
|
|
|
|
|
|
|
lastDelivered := net.delivered.LoadID(target, dc.clientName)
|
|
|
|
if lastDelivered == "" {
|
2021-02-10 12:48:41 +00:00
|
|
|
return
|
|
|
|
}
|
2020-04-28 13:27:41 +00:00
|
|
|
|
2021-02-10 12:48:41 +00:00
|
|
|
limit := 4000
|
2021-03-29 15:07:39 +00:00
|
|
|
targetCM := net.casemap(target)
|
|
|
|
history, err := dc.user.msgStore.LoadLatestID(net, targetCM, lastDelivered, limit)
|
2021-02-10 12:48:41 +00:00
|
|
|
if err != nil {
|
|
|
|
dc.logger.Printf("failed to send implicit history for %q: %v", target, err)
|
|
|
|
return
|
|
|
|
}
|
2020-03-25 10:28:25 +00:00
|
|
|
|
2021-02-10 12:48:41 +00:00
|
|
|
batchRef := "history"
|
|
|
|
if dc.caps["batch"] {
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "BATCH",
|
|
|
|
Params: []string{"+" + batchRef, "chathistory", dc.marshalEntity(net, target)},
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, msg := range history {
|
|
|
|
if !dc.messageSupportsHistory(msg) {
|
2020-08-19 11:24:05 +00:00
|
|
|
continue
|
|
|
|
}
|
2020-02-17 14:46:29 +00:00
|
|
|
|
2020-04-15 09:29:15 +00:00
|
|
|
if dc.caps["batch"] {
|
2021-02-10 12:48:41 +00:00
|
|
|
msg.Tags["batch"] = irc.TagValue(batchRef)
|
2020-03-25 10:28:25 +00:00
|
|
|
}
|
2021-02-10 12:48:41 +00:00
|
|
|
dc.SendMessage(dc.marshalMessage(msg, net))
|
|
|
|
}
|
2020-04-15 09:29:15 +00:00
|
|
|
|
2021-02-10 12:48:41 +00:00
|
|
|
if dc.caps["batch"] {
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "BATCH",
|
|
|
|
Params: []string{"-" + batchRef},
|
|
|
|
})
|
2020-04-10 17:22:47 +00:00
|
|
|
}
|
2020-02-06 15:18:19 +00:00
|
|
|
}
|
|
|
|
|
2020-03-16 11:44:59 +00:00
|
|
|
func (dc *downstreamConn) runUntilRegistered() error {
|
|
|
|
for !dc.registered {
|
2020-04-03 15:01:25 +00:00
|
|
|
msg, err := dc.ReadMessage()
|
2020-03-16 13:30:49 +00:00
|
|
|
if err != nil {
|
2020-03-16 11:44:59 +00:00
|
|
|
return fmt.Errorf("failed to read IRC command: %v", err)
|
|
|
|
}
|
|
|
|
|
|
|
|
err = dc.handleMessage(msg)
|
|
|
|
if ircErr, ok := err.(ircError); ok {
|
|
|
|
ircErr.Message.Prefix = dc.srv.prefix()
|
|
|
|
dc.SendMessage(ircErr.Message)
|
|
|
|
} else if err != nil {
|
|
|
|
return fmt.Errorf("failed to handle IRC command %q: %v", msg, err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-02-17 11:36:42 +00:00
|
|
|
func (dc *downstreamConn) handleMessageRegistered(msg *irc.Message) error {
|
2020-02-06 15:18:19 +00:00
|
|
|
switch msg.Command {
|
2020-03-16 14:11:08 +00:00
|
|
|
case "CAP":
|
|
|
|
var subCmd string
|
|
|
|
if err := parseMessageParams(msg, &subCmd); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if err := dc.handleCapCommand(subCmd, msg.Params[1:]); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-03-16 13:32:38 +00:00
|
|
|
case "PING":
|
2020-08-26 13:18:57 +00:00
|
|
|
var source, destination string
|
|
|
|
if err := parseMessageParams(msg, &source); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
if len(msg.Params) > 1 {
|
|
|
|
destination = msg.Params[1]
|
|
|
|
}
|
|
|
|
if destination != "" && destination != dc.srv.Hostname {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NOSUCHSERVER,
|
2020-08-26 13:28:10 +00:00
|
|
|
Params: []string{dc.nick, destination, "No such server"},
|
2020-08-26 13:18:57 +00:00
|
|
|
}}
|
|
|
|
}
|
2020-03-16 13:32:38 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "PONG",
|
2020-08-26 13:18:57 +00:00
|
|
|
Params: []string{dc.srv.Hostname, source},
|
2020-03-16 13:32:38 +00:00
|
|
|
})
|
|
|
|
return nil
|
2020-08-28 15:21:08 +00:00
|
|
|
case "PONG":
|
|
|
|
if len(msg.Params) == 0 {
|
|
|
|
return newNeedMoreParamsError(msg.Command)
|
|
|
|
}
|
|
|
|
token := msg.Params[len(msg.Params)-1]
|
|
|
|
dc.handlePong(token)
|
2020-02-07 11:19:42 +00:00
|
|
|
case "USER":
|
2020-02-06 15:18:19 +00:00
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_ALREADYREGISTERED,
|
2020-02-17 11:36:42 +00:00
|
|
|
Params: []string{dc.nick, "You may not reregister"},
|
2020-02-06 15:18:19 +00:00
|
|
|
}}
|
2020-02-07 11:19:42 +00:00
|
|
|
case "NICK":
|
2020-11-23 16:09:31 +00:00
|
|
|
var rawNick string
|
|
|
|
if err := parseMessageParams(msg, &rawNick); err != nil {
|
2020-03-12 18:17:06 +00:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2020-11-23 16:09:31 +00:00
|
|
|
nick := rawNick
|
2020-05-08 18:24:59 +00:00
|
|
|
var upstream *upstreamConn
|
|
|
|
if dc.upstream() == nil {
|
|
|
|
uc, unmarshaledNick, err := dc.unmarshalEntity(nick)
|
|
|
|
if err == nil { // NICK nick/network: NICK only on a specific upstream
|
|
|
|
upstream = uc
|
|
|
|
nick = unmarshaledNick
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-08-20 08:00:58 +00:00
|
|
|
if strings.ContainsAny(nick, illegalNickChars) {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_ERRONEUSNICKNAME,
|
2020-11-24 13:22:39 +00:00
|
|
|
Params: []string{dc.nick, rawNick, "contains illegal characters"},
|
2020-08-20 08:00:58 +00:00
|
|
|
}}
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
if casemapASCII(nick) == serviceNickCM {
|
2020-11-23 16:09:31 +00:00
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NICKNAMEINUSE,
|
|
|
|
Params: []string{dc.nick, rawNick, "Nickname reserved for bouncer service"},
|
|
|
|
}}
|
|
|
|
}
|
2020-08-20 08:00:58 +00:00
|
|
|
|
2020-03-12 18:17:06 +00:00
|
|
|
var err error
|
|
|
|
dc.forEachNetwork(func(n *network) {
|
2020-05-08 18:24:59 +00:00
|
|
|
if err != nil || (upstream != nil && upstream.network != n) {
|
2020-03-12 18:17:06 +00:00
|
|
|
return
|
|
|
|
}
|
|
|
|
n.Nick = nick
|
2020-10-24 13:14:23 +00:00
|
|
|
err = dc.srv.db.StoreNetwork(dc.user.ID, &n.Network)
|
2020-03-12 18:17:06 +00:00
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2020-03-04 14:44:13 +00:00
|
|
|
dc.forEachUpstream(func(uc *upstreamConn) {
|
2020-05-08 18:24:59 +00:00
|
|
|
if upstream != nil && upstream != uc {
|
|
|
|
return
|
|
|
|
}
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-05-08 18:24:59 +00:00
|
|
|
Command: "NICK",
|
|
|
|
Params: []string{nick},
|
|
|
|
})
|
2020-02-07 11:19:42 +00:00
|
|
|
})
|
2020-04-30 22:37:42 +00:00
|
|
|
|
|
|
|
if dc.upstream() == nil && dc.nick != nick {
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.prefix(),
|
|
|
|
Command: "NICK",
|
|
|
|
Params: []string{nick},
|
|
|
|
})
|
|
|
|
dc.nick = nick
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
dc.nickCM = casemapASCII(dc.nick)
|
2020-04-30 22:37:42 +00:00
|
|
|
}
|
2020-03-25 10:52:24 +00:00
|
|
|
case "JOIN":
|
|
|
|
var namesStr string
|
|
|
|
if err := parseMessageParams(msg, &namesStr); err != nil {
|
2020-02-07 12:36:32 +00:00
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2020-03-25 10:52:24 +00:00
|
|
|
var keys []string
|
|
|
|
if len(msg.Params) > 1 {
|
|
|
|
keys = strings.Split(msg.Params[1], ",")
|
|
|
|
}
|
|
|
|
|
|
|
|
for i, name := range strings.Split(namesStr, ",") {
|
2020-03-25 10:32:44 +00:00
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(name)
|
2020-03-12 17:33:03 +00:00
|
|
|
if err != nil {
|
2020-03-25 22:56:01 +00:00
|
|
|
return err
|
2020-03-12 17:33:03 +00:00
|
|
|
}
|
2020-03-25 10:32:44 +00:00
|
|
|
|
2020-03-25 10:52:24 +00:00
|
|
|
var key string
|
|
|
|
if len(keys) > i {
|
|
|
|
key = keys[i]
|
|
|
|
}
|
|
|
|
|
|
|
|
params := []string{upstreamName}
|
|
|
|
if key != "" {
|
|
|
|
params = append(params, key)
|
|
|
|
}
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-25 10:52:24 +00:00
|
|
|
Command: "JOIN",
|
|
|
|
Params: params,
|
2020-03-25 10:32:44 +00:00
|
|
|
})
|
|
|
|
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
ch := uc.network.channels.Value(upstreamName)
|
|
|
|
if ch != nil {
|
2020-05-01 15:39:53 +00:00
|
|
|
// Don't clear the channel key if there's one set
|
|
|
|
// TODO: add a way to unset the channel key
|
Add customizable auto-detaching, auto-reattaching, relaying.
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
2020-11-30 21:08:33 +00:00
|
|
|
if key != "" {
|
|
|
|
ch.Key = key
|
|
|
|
}
|
|
|
|
uc.network.attach(ch)
|
|
|
|
} else {
|
|
|
|
ch = &Channel{
|
|
|
|
Name: upstreamName,
|
|
|
|
Key: key,
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
uc.network.channels.SetValue(upstreamName, ch)
|
2020-05-01 15:39:53 +00:00
|
|
|
}
|
Add customizable auto-detaching, auto-reattaching, relaying.
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
2020-11-30 21:08:33 +00:00
|
|
|
if err := dc.srv.db.StoreChannel(uc.network.ID, ch); err != nil {
|
2020-04-05 13:04:52 +00:00
|
|
|
dc.logger.Printf("failed to create or update channel %q: %v", upstreamName, err)
|
2020-03-25 10:52:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
case "PART":
|
|
|
|
var namesStr string
|
|
|
|
if err := parseMessageParams(msg, &namesStr); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
var reason string
|
|
|
|
if len(msg.Params) > 1 {
|
|
|
|
reason = msg.Params[1]
|
|
|
|
}
|
|
|
|
|
|
|
|
for _, name := range strings.Split(namesStr, ",") {
|
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(name)
|
|
|
|
if err != nil {
|
2020-03-25 22:56:01 +00:00
|
|
|
return err
|
2020-03-25 10:52:24 +00:00
|
|
|
}
|
|
|
|
|
2020-04-28 13:27:41 +00:00
|
|
|
if strings.EqualFold(reason, "detach") {
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
ch := uc.network.channels.Value(upstreamName)
|
|
|
|
if ch != nil {
|
Add customizable auto-detaching, auto-reattaching, relaying.
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
2020-11-30 21:08:33 +00:00
|
|
|
uc.network.detach(ch)
|
|
|
|
} else {
|
|
|
|
ch = &Channel{
|
|
|
|
Name: name,
|
|
|
|
Detached: true,
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
uc.network.channels.SetValue(upstreamName, ch)
|
Add customizable auto-detaching, auto-reattaching, relaying.
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
2020-11-30 21:08:33 +00:00
|
|
|
}
|
|
|
|
if err := dc.srv.db.StoreChannel(uc.network.ID, ch); err != nil {
|
|
|
|
dc.logger.Printf("failed to create or update channel %q: %v", upstreamName, err)
|
2020-04-28 13:27:41 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
params := []string{upstreamName}
|
|
|
|
if reason != "" {
|
|
|
|
params = append(params, reason)
|
|
|
|
}
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-04-28 13:27:41 +00:00
|
|
|
Command: "PART",
|
|
|
|
Params: params,
|
|
|
|
})
|
2020-03-25 10:52:24 +00:00
|
|
|
|
2020-04-28 13:27:41 +00:00
|
|
|
if err := uc.network.deleteChannel(upstreamName); err != nil {
|
|
|
|
dc.logger.Printf("failed to delete channel %q: %v", upstreamName, err)
|
|
|
|
}
|
2020-03-12 17:33:03 +00:00
|
|
|
}
|
|
|
|
}
|
2020-03-25 22:46:36 +00:00
|
|
|
case "KICK":
|
|
|
|
var channelStr, userStr string
|
|
|
|
if err := parseMessageParams(msg, &channelStr, &userStr); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
channels := strings.Split(channelStr, ",")
|
|
|
|
users := strings.Split(userStr, ",")
|
|
|
|
|
|
|
|
var reason string
|
|
|
|
if len(msg.Params) > 2 {
|
|
|
|
reason = msg.Params[2]
|
|
|
|
}
|
|
|
|
|
|
|
|
if len(channels) != 1 && len(channels) != len(users) {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_BADCHANMASK,
|
|
|
|
Params: []string{dc.nick, channelStr, "Bad channel mask"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
for i, user := range users {
|
|
|
|
var channel string
|
|
|
|
if len(channels) == 1 {
|
|
|
|
channel = channels[0]
|
|
|
|
} else {
|
|
|
|
channel = channels[i]
|
|
|
|
}
|
|
|
|
|
|
|
|
ucChannel, upstreamChannel, err := dc.unmarshalEntity(channel)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
ucUser, upstreamUser, err := dc.unmarshalEntity(user)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if ucChannel != ucUser {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_USERNOTINCHANNEL,
|
2020-08-18 11:54:44 +00:00
|
|
|
Params: []string{dc.nick, user, channel, "They are on another network"},
|
2020-03-25 22:46:36 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
uc := ucChannel
|
|
|
|
|
|
|
|
params := []string{upstreamChannel, upstreamUser}
|
|
|
|
if reason != "" {
|
|
|
|
params = append(params, reason)
|
|
|
|
}
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-25 22:46:36 +00:00
|
|
|
Command: "KICK",
|
|
|
|
Params: params,
|
|
|
|
})
|
|
|
|
}
|
2020-02-07 12:08:27 +00:00
|
|
|
case "MODE":
|
|
|
|
var name string
|
|
|
|
if err := parseMessageParams(msg, &name); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
var modeStr string
|
|
|
|
if len(msg.Params) > 1 {
|
|
|
|
modeStr = msg.Params[1]
|
|
|
|
}
|
|
|
|
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
if casemapASCII(name) == dc.nickCM {
|
2020-02-07 12:08:27 +00:00
|
|
|
if modeStr != "" {
|
2020-03-04 14:44:13 +00:00
|
|
|
dc.forEachUpstream(func(uc *upstreamConn) {
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-02-19 17:25:19 +00:00
|
|
|
Command: "MODE",
|
|
|
|
Params: []string{uc.nick, modeStr},
|
|
|
|
})
|
2020-02-07 12:08:27 +00:00
|
|
|
})
|
|
|
|
} else {
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
2020-02-07 12:08:27 +00:00
|
|
|
Command: irc.RPL_UMODEIS,
|
2020-03-20 02:05:14 +00:00
|
|
|
Params: []string{dc.nick, ""}, // TODO
|
2020-02-17 11:27:48 +00:00
|
|
|
})
|
2020-02-07 12:08:27 +00:00
|
|
|
}
|
2020-03-20 23:48:19 +00:00
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(name)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if !uc.isChannel(upstreamName) {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_USERSDONTMATCH,
|
|
|
|
Params: []string{dc.nick, "Cannot change mode for other users"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
if modeStr != "" {
|
|
|
|
params := []string{upstreamName, modeStr}
|
|
|
|
params = append(params, msg.Params[2:]...)
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-20 23:48:19 +00:00
|
|
|
Command: "MODE",
|
|
|
|
Params: params,
|
|
|
|
})
|
|
|
|
} else {
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
ch := uc.channels.Value(upstreamName)
|
|
|
|
if ch == nil {
|
2020-03-20 23:48:19 +00:00
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NOSUCHCHANNEL,
|
|
|
|
Params: []string{dc.nick, name, "No such channel"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ch.modes == nil {
|
|
|
|
// we haven't received the initial RPL_CHANNELMODEIS yet
|
|
|
|
// ignore the request, we will broadcast the modes later when we receive RPL_CHANNELMODEIS
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
modeStr, modeParams := ch.modes.Format()
|
|
|
|
params := []string{dc.nick, name, modeStr}
|
|
|
|
params = append(params, modeParams...)
|
|
|
|
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_CHANNELMODEIS,
|
|
|
|
Params: params,
|
|
|
|
})
|
2020-03-26 04:51:47 +00:00
|
|
|
if ch.creationTime != "" {
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: rpl_creationtime,
|
|
|
|
Params: []string{dc.nick, name, ch.creationTime},
|
|
|
|
})
|
|
|
|
}
|
2020-02-07 12:08:27 +00:00
|
|
|
}
|
2020-03-25 23:19:45 +00:00
|
|
|
case "TOPIC":
|
|
|
|
var channel string
|
|
|
|
if err := parseMessageParams(msg, &channel); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(channel)
|
2020-03-25 23:19:45 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if len(msg.Params) > 1 { // setting topic
|
|
|
|
topic := msg.Params[1]
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-25 23:19:45 +00:00
|
|
|
Command: "TOPIC",
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
Params: []string{upstreamName, topic},
|
2020-03-25 23:19:45 +00:00
|
|
|
})
|
|
|
|
} else { // getting topic
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
ch := uc.channels.Value(upstreamName)
|
|
|
|
if ch == nil {
|
2020-03-25 23:19:45 +00:00
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NOSUCHCHANNEL,
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
Params: []string{dc.nick, upstreamName, "No such channel"},
|
2020-03-25 23:19:45 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
sendTopic(dc, ch)
|
|
|
|
}
|
Add LIST support
This commit adds support for downstream LIST messages from multiple
concurrent downstreams to multiple concurrent upstreams, including
support for multiple pending LIST requests from the same downstream.
Because a unique RPL_LISTEND message must be sent to the requesting
downstream, and that there might be multiple upstreams, each sending
their own RPL_LISTEND, a cache of RPL_LISTEND replies of some sort is
required to match RPL_LISTEND together in order to only send one back
downstream.
This commit adds a list of "pending LIST" structs, which each contain a
map of all upstreams that yet need to send a RPL_LISTEND, and the
corresponding LIST request associated with that response. This list of
pending LISTs is sorted according to the order that the requesting
downstreams sent the LIST messages in. Each pending set also stores the
id of the requesting downstream, in order to only forward the replies to
it and no other downstream. (This is important because LIST replies can
typically amount to several thousands messages on large servers.)
When a single downstream makes multiple LIST requests, only the first
one will be immediately sent to the upstream servers. The next ones will
be buffered until the first one is completed. Distinct downstreams can
make concurrent LIST requests without any request buffering.
Each RPL_LIST message is forwarded to the downstream of the first
matching pending LIST struct.
When an upstream sends an RPL_LISTEND message, the upstream is removed
from the first matching pending LIST struct, but that message is not
immediately forwarded downstream. If there are no remaining pending LIST
requests in that struct is then empty, that means all upstreams have
sent back all their RPL_LISTEND replies (which means they also sent all
their RPL_LIST replies); so a unique RPL_LISTEND is sent to downstream
and that pending LIST set is removed from the cache.
Upstreams are removed from the pending LIST structs in two other cases:
- when they are closed (to avoid stalling because of a disconnected
upstream that will never reply to the LIST message): they are removed
from all pending LIST structs
- when they reply with an ERR_UNKNOWNCOMMAND or RPL_TRYAGAIN LIST reply,
which is typically used when a user is not allowed to LIST because they
just joined the server: they are removed from the first pending LIST
struct, as if an RPL_LISTEND message was received
2020-03-26 01:40:30 +00:00
|
|
|
case "LIST":
|
|
|
|
// TODO: support ELIST when supported by all upstreams
|
|
|
|
|
|
|
|
pl := pendingLIST{
|
|
|
|
downstreamID: dc.id,
|
|
|
|
pendingCommands: make(map[int64]*irc.Message),
|
|
|
|
}
|
2020-05-08 18:27:21 +00:00
|
|
|
var upstream *upstreamConn
|
Add LIST support
This commit adds support for downstream LIST messages from multiple
concurrent downstreams to multiple concurrent upstreams, including
support for multiple pending LIST requests from the same downstream.
Because a unique RPL_LISTEND message must be sent to the requesting
downstream, and that there might be multiple upstreams, each sending
their own RPL_LISTEND, a cache of RPL_LISTEND replies of some sort is
required to match RPL_LISTEND together in order to only send one back
downstream.
This commit adds a list of "pending LIST" structs, which each contain a
map of all upstreams that yet need to send a RPL_LISTEND, and the
corresponding LIST request associated with that response. This list of
pending LISTs is sorted according to the order that the requesting
downstreams sent the LIST messages in. Each pending set also stores the
id of the requesting downstream, in order to only forward the replies to
it and no other downstream. (This is important because LIST replies can
typically amount to several thousands messages on large servers.)
When a single downstream makes multiple LIST requests, only the first
one will be immediately sent to the upstream servers. The next ones will
be buffered until the first one is completed. Distinct downstreams can
make concurrent LIST requests without any request buffering.
Each RPL_LIST message is forwarded to the downstream of the first
matching pending LIST struct.
When an upstream sends an RPL_LISTEND message, the upstream is removed
from the first matching pending LIST struct, but that message is not
immediately forwarded downstream. If there are no remaining pending LIST
requests in that struct is then empty, that means all upstreams have
sent back all their RPL_LISTEND replies (which means they also sent all
their RPL_LIST replies); so a unique RPL_LISTEND is sent to downstream
and that pending LIST set is removed from the cache.
Upstreams are removed from the pending LIST structs in two other cases:
- when they are closed (to avoid stalling because of a disconnected
upstream that will never reply to the LIST message): they are removed
from all pending LIST structs
- when they reply with an ERR_UNKNOWNCOMMAND or RPL_TRYAGAIN LIST reply,
which is typically used when a user is not allowed to LIST because they
just joined the server: they are removed from the first pending LIST
struct, as if an RPL_LISTEND message was received
2020-03-26 01:40:30 +00:00
|
|
|
var upstreamChannels map[int64][]string
|
|
|
|
if len(msg.Params) > 0 {
|
2020-05-08 18:27:21 +00:00
|
|
|
uc, upstreamMask, err := dc.unmarshalEntity(msg.Params[0])
|
|
|
|
if err == nil && upstreamMask == "*" { // LIST */network: send LIST only to one network
|
|
|
|
upstream = uc
|
|
|
|
} else {
|
|
|
|
upstreamChannels = make(map[int64][]string)
|
|
|
|
channels := strings.Split(msg.Params[0], ",")
|
|
|
|
for _, channel := range channels {
|
|
|
|
uc, upstreamChannel, err := dc.unmarshalEntity(channel)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
upstreamChannels[uc.network.ID] = append(upstreamChannels[uc.network.ID], upstreamChannel)
|
Add LIST support
This commit adds support for downstream LIST messages from multiple
concurrent downstreams to multiple concurrent upstreams, including
support for multiple pending LIST requests from the same downstream.
Because a unique RPL_LISTEND message must be sent to the requesting
downstream, and that there might be multiple upstreams, each sending
their own RPL_LISTEND, a cache of RPL_LISTEND replies of some sort is
required to match RPL_LISTEND together in order to only send one back
downstream.
This commit adds a list of "pending LIST" structs, which each contain a
map of all upstreams that yet need to send a RPL_LISTEND, and the
corresponding LIST request associated with that response. This list of
pending LISTs is sorted according to the order that the requesting
downstreams sent the LIST messages in. Each pending set also stores the
id of the requesting downstream, in order to only forward the replies to
it and no other downstream. (This is important because LIST replies can
typically amount to several thousands messages on large servers.)
When a single downstream makes multiple LIST requests, only the first
one will be immediately sent to the upstream servers. The next ones will
be buffered until the first one is completed. Distinct downstreams can
make concurrent LIST requests without any request buffering.
Each RPL_LIST message is forwarded to the downstream of the first
matching pending LIST struct.
When an upstream sends an RPL_LISTEND message, the upstream is removed
from the first matching pending LIST struct, but that message is not
immediately forwarded downstream. If there are no remaining pending LIST
requests in that struct is then empty, that means all upstreams have
sent back all their RPL_LISTEND replies (which means they also sent all
their RPL_LIST replies); so a unique RPL_LISTEND is sent to downstream
and that pending LIST set is removed from the cache.
Upstreams are removed from the pending LIST structs in two other cases:
- when they are closed (to avoid stalling because of a disconnected
upstream that will never reply to the LIST message): they are removed
from all pending LIST structs
- when they reply with an ERR_UNKNOWNCOMMAND or RPL_TRYAGAIN LIST reply,
which is typically used when a user is not allowed to LIST because they
just joined the server: they are removed from the first pending LIST
struct, as if an RPL_LISTEND message was received
2020-03-26 01:40:30 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.user.pendingLISTs = append(dc.user.pendingLISTs, pl)
|
|
|
|
dc.forEachUpstream(func(uc *upstreamConn) {
|
2020-05-08 18:27:21 +00:00
|
|
|
if upstream != nil && upstream != uc {
|
|
|
|
return
|
|
|
|
}
|
Add LIST support
This commit adds support for downstream LIST messages from multiple
concurrent downstreams to multiple concurrent upstreams, including
support for multiple pending LIST requests from the same downstream.
Because a unique RPL_LISTEND message must be sent to the requesting
downstream, and that there might be multiple upstreams, each sending
their own RPL_LISTEND, a cache of RPL_LISTEND replies of some sort is
required to match RPL_LISTEND together in order to only send one back
downstream.
This commit adds a list of "pending LIST" structs, which each contain a
map of all upstreams that yet need to send a RPL_LISTEND, and the
corresponding LIST request associated with that response. This list of
pending LISTs is sorted according to the order that the requesting
downstreams sent the LIST messages in. Each pending set also stores the
id of the requesting downstream, in order to only forward the replies to
it and no other downstream. (This is important because LIST replies can
typically amount to several thousands messages on large servers.)
When a single downstream makes multiple LIST requests, only the first
one will be immediately sent to the upstream servers. The next ones will
be buffered until the first one is completed. Distinct downstreams can
make concurrent LIST requests without any request buffering.
Each RPL_LIST message is forwarded to the downstream of the first
matching pending LIST struct.
When an upstream sends an RPL_LISTEND message, the upstream is removed
from the first matching pending LIST struct, but that message is not
immediately forwarded downstream. If there are no remaining pending LIST
requests in that struct is then empty, that means all upstreams have
sent back all their RPL_LISTEND replies (which means they also sent all
their RPL_LIST replies); so a unique RPL_LISTEND is sent to downstream
and that pending LIST set is removed from the cache.
Upstreams are removed from the pending LIST structs in two other cases:
- when they are closed (to avoid stalling because of a disconnected
upstream that will never reply to the LIST message): they are removed
from all pending LIST structs
- when they reply with an ERR_UNKNOWNCOMMAND or RPL_TRYAGAIN LIST reply,
which is typically used when a user is not allowed to LIST because they
just joined the server: they are removed from the first pending LIST
struct, as if an RPL_LISTEND message was received
2020-03-26 01:40:30 +00:00
|
|
|
var params []string
|
|
|
|
if upstreamChannels != nil {
|
|
|
|
if channels, ok := upstreamChannels[uc.network.ID]; ok {
|
|
|
|
params = []string{strings.Join(channels, ",")}
|
|
|
|
} else {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
}
|
|
|
|
pl.pendingCommands[uc.network.ID] = &irc.Message{
|
|
|
|
Command: "LIST",
|
|
|
|
Params: params,
|
|
|
|
}
|
2020-03-28 00:03:00 +00:00
|
|
|
uc.trySendLIST(dc.id)
|
Add LIST support
This commit adds support for downstream LIST messages from multiple
concurrent downstreams to multiple concurrent upstreams, including
support for multiple pending LIST requests from the same downstream.
Because a unique RPL_LISTEND message must be sent to the requesting
downstream, and that there might be multiple upstreams, each sending
their own RPL_LISTEND, a cache of RPL_LISTEND replies of some sort is
required to match RPL_LISTEND together in order to only send one back
downstream.
This commit adds a list of "pending LIST" structs, which each contain a
map of all upstreams that yet need to send a RPL_LISTEND, and the
corresponding LIST request associated with that response. This list of
pending LISTs is sorted according to the order that the requesting
downstreams sent the LIST messages in. Each pending set also stores the
id of the requesting downstream, in order to only forward the replies to
it and no other downstream. (This is important because LIST replies can
typically amount to several thousands messages on large servers.)
When a single downstream makes multiple LIST requests, only the first
one will be immediately sent to the upstream servers. The next ones will
be buffered until the first one is completed. Distinct downstreams can
make concurrent LIST requests without any request buffering.
Each RPL_LIST message is forwarded to the downstream of the first
matching pending LIST struct.
When an upstream sends an RPL_LISTEND message, the upstream is removed
from the first matching pending LIST struct, but that message is not
immediately forwarded downstream. If there are no remaining pending LIST
requests in that struct is then empty, that means all upstreams have
sent back all their RPL_LISTEND replies (which means they also sent all
their RPL_LIST replies); so a unique RPL_LISTEND is sent to downstream
and that pending LIST set is removed from the cache.
Upstreams are removed from the pending LIST structs in two other cases:
- when they are closed (to avoid stalling because of a disconnected
upstream that will never reply to the LIST message): they are removed
from all pending LIST structs
- when they reply with an ERR_UNKNOWNCOMMAND or RPL_TRYAGAIN LIST reply,
which is typically used when a user is not allowed to LIST because they
just joined the server: they are removed from the first pending LIST
struct, as if an RPL_LISTEND message was received
2020-03-26 01:40:30 +00:00
|
|
|
})
|
2020-03-21 00:24:29 +00:00
|
|
|
case "NAMES":
|
|
|
|
if len(msg.Params) == 0 {
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_ENDOFNAMES,
|
|
|
|
Params: []string{dc.nick, "*", "End of /NAMES list"},
|
|
|
|
})
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
channels := strings.Split(msg.Params[0], ",")
|
|
|
|
for _, channel := range channels {
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(channel)
|
2020-03-21 00:24:29 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
ch := uc.channels.Value(upstreamName)
|
|
|
|
if ch != nil {
|
2020-03-21 00:24:29 +00:00
|
|
|
sendNames(dc, ch)
|
|
|
|
} else {
|
|
|
|
// NAMES on a channel we have not joined, ask upstream
|
2020-03-26 03:30:11 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-21 00:24:29 +00:00
|
|
|
Command: "NAMES",
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
Params: []string{upstreamName},
|
2020-03-21 00:24:29 +00:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
2020-03-19 23:23:19 +00:00
|
|
|
case "WHO":
|
|
|
|
if len(msg.Params) == 0 {
|
|
|
|
// TODO: support WHO without parameters
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_ENDOFWHO,
|
2020-03-21 00:24:29 +00:00
|
|
|
Params: []string{dc.nick, "*", "End of /WHO list"},
|
2020-03-19 23:23:19 +00:00
|
|
|
})
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: support WHO masks
|
|
|
|
entity := msg.Params[0]
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
entityCM := casemapASCII(entity)
|
2020-03-19 23:23:19 +00:00
|
|
|
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
if entityCM == dc.nickCM {
|
2020-03-21 23:46:56 +00:00
|
|
|
// TODO: support AWAY (H/G) in self WHO reply
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_WHOREPLY,
|
2020-03-28 16:28:28 +00:00
|
|
|
Params: []string{dc.nick, "*", dc.user.Username, dc.hostname, dc.srv.Hostname, dc.nick, "H", "0 " + dc.realname},
|
2020-03-21 23:46:56 +00:00
|
|
|
})
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_ENDOFWHO,
|
|
|
|
Params: []string{dc.nick, dc.nick, "End of /WHO list"},
|
|
|
|
})
|
|
|
|
return nil
|
|
|
|
}
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
if entityCM == serviceNickCM {
|
2020-06-29 16:09:48 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_WHOREPLY,
|
|
|
|
Params: []string{serviceNick, "*", servicePrefix.User, servicePrefix.Host, dc.srv.Hostname, serviceNick, "H", "0 " + serviceRealname},
|
|
|
|
})
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_ENDOFWHO,
|
|
|
|
Params: []string{dc.nick, serviceNick, "End of /WHO list"},
|
|
|
|
})
|
|
|
|
return nil
|
|
|
|
}
|
2020-03-21 23:46:56 +00:00
|
|
|
|
2020-03-19 23:23:19 +00:00
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(entity)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
var params []string
|
|
|
|
if len(msg.Params) == 2 {
|
|
|
|
params = []string{upstreamName, msg.Params[1]}
|
|
|
|
} else {
|
|
|
|
params = []string{upstreamName}
|
|
|
|
}
|
|
|
|
|
2020-03-26 03:30:11 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-19 23:23:19 +00:00
|
|
|
Command: "WHO",
|
|
|
|
Params: params,
|
|
|
|
})
|
2020-03-20 01:15:23 +00:00
|
|
|
case "WHOIS":
|
|
|
|
if len(msg.Params) == 0 {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_NONICKNAMEGIVEN,
|
|
|
|
Params: []string{dc.nick, "No nickname given"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
var target, mask string
|
|
|
|
if len(msg.Params) == 1 {
|
|
|
|
target = ""
|
|
|
|
mask = msg.Params[0]
|
|
|
|
} else {
|
|
|
|
target = msg.Params[0]
|
|
|
|
mask = msg.Params[1]
|
|
|
|
}
|
|
|
|
// TODO: support multiple WHOIS users
|
|
|
|
if i := strings.IndexByte(mask, ','); i >= 0 {
|
|
|
|
mask = mask[:i]
|
|
|
|
}
|
|
|
|
|
Implement casemapping
TL;DR: supports for casemapping, now logs are saved in
casemapped/canonical/tolower form
(eg. in the #channel directory instead of #Channel... or something)
== What is casemapping? ==
see <https://modern.ircdocs.horse/#casemapping-parameter>
== Casemapping and multi-upstream ==
Since each upstream does not necessarily use the same casemapping, and
since casemappings cannot coexist [0],
1. soju must also update the database accordingly to upstreams'
casemapping, otherwise it will end up inconsistent,
2. soju must "normalize" entity names and expose only one casemapping
that is a subset of all supported casemappings (here, ascii).
[0] On some upstreams, "emersion[m]" and "emersion{m}" refer to the same
user (upstreams that advertise rfc1459 for example), while on others
(upstreams that advertise ascii) they don't.
Once upstream's casemapping is known (default to rfc1459), entity names
in map keys are made into casemapped form, for upstreamConn,
upstreamChannel and network.
downstreamConn advertises "CASEMAPPING=ascii", and always casemap map
keys with ascii.
Some functions require the caller to casemap their argument (to avoid
needless calls to casemapping functions).
== Message forwarding and casemapping ==
downstream message handling (joins and parts basically):
When relaying entity names from downstreams to upstreams, soju uses the
upstream casemapping, in order to not get in the way of the user. This
does not brings any issue, as long as soju replies with the ascii
casemapping in mind (solves point 1.).
marshalEntity/marshalUserPrefix:
When relaying entity names from upstreams with non-ascii casemappings,
soju *partially* casemap them: it only change the case of characters
which are not ascii letters. ASCII case is thus kept intact, while
special symbols like []{} are the same every time soju sends them to
downstreams (solves point 2.).
== Casemapping changes ==
Casemapping changes are not fully supported by this patch and will
result in loss of history. This is a limitation of the protocol and
should be solved by the RENAME spec.
2021-03-16 09:00:34 +00:00
|
|
|
if casemapASCII(mask) == dc.nickCM {
|
2020-03-21 23:46:56 +00:00
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_WHOISUSER,
|
2020-03-28 16:28:28 +00:00
|
|
|
Params: []string{dc.nick, dc.nick, dc.user.Username, dc.hostname, "*", dc.realname},
|
2020-03-21 23:46:56 +00:00
|
|
|
})
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_WHOISSERVER,
|
|
|
|
Params: []string{dc.nick, dc.nick, dc.srv.Hostname, "soju"},
|
|
|
|
})
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: irc.RPL_ENDOFWHOIS,
|
|
|
|
Params: []string{dc.nick, dc.nick, "End of /WHOIS list"},
|
|
|
|
})
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2020-03-20 01:15:23 +00:00
|
|
|
// TODO: support WHOIS masks
|
|
|
|
uc, upstreamNick, err := dc.unmarshalEntity(mask)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
var params []string
|
|
|
|
if target != "" {
|
2020-05-11 21:48:07 +00:00
|
|
|
if target == mask { // WHOIS nick nick
|
|
|
|
params = []string{upstreamNick, upstreamNick}
|
|
|
|
} else {
|
|
|
|
params = []string{target, upstreamNick}
|
|
|
|
}
|
2020-03-20 01:15:23 +00:00
|
|
|
} else {
|
|
|
|
params = []string{upstreamNick}
|
|
|
|
}
|
|
|
|
|
2020-03-26 03:30:11 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-20 01:15:23 +00:00
|
|
|
Command: "WHOIS",
|
|
|
|
Params: params,
|
|
|
|
})
|
2020-02-17 14:56:18 +00:00
|
|
|
case "PRIVMSG":
|
|
|
|
var targetsStr, text string
|
|
|
|
if err := parseMessageParams(msg, &targetsStr, &text); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-05-21 05:04:34 +00:00
|
|
|
tags := copyClientTags(msg.Tags)
|
2020-02-17 14:56:18 +00:00
|
|
|
|
|
|
|
for _, name := range strings.Split(targetsStr, ",") {
|
2020-03-18 11:23:08 +00:00
|
|
|
if name == serviceNick {
|
2020-11-23 16:14:42 +00:00
|
|
|
if dc.caps["echo-message"] {
|
|
|
|
echoTags := tags.Copy()
|
|
|
|
echoTags["time"] = irc.TagValue(time.Now().UTC().Format(serverTimeLayout))
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Tags: echoTags,
|
|
|
|
Prefix: dc.prefix(),
|
|
|
|
Command: "PRIVMSG",
|
|
|
|
Params: []string{name, text},
|
|
|
|
})
|
|
|
|
}
|
2020-03-18 11:23:08 +00:00
|
|
|
handleServicePRIVMSG(dc, text)
|
|
|
|
continue
|
|
|
|
}
|
|
|
|
|
2020-03-19 23:23:19 +00:00
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(name)
|
2020-02-17 14:56:18 +00:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2021-03-30 10:28:45 +00:00
|
|
|
if uc.network.casemap(upstreamName) == "nickserv" {
|
2020-03-13 14:12:44 +00:00
|
|
|
dc.handleNickServPRIVMSG(uc, text)
|
|
|
|
}
|
|
|
|
|
2020-04-21 20:54:45 +00:00
|
|
|
unmarshaledText := text
|
|
|
|
if uc.isChannel(upstreamName) {
|
|
|
|
unmarshaledText = dc.unmarshalText(uc, text)
|
|
|
|
}
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-05-21 05:04:34 +00:00
|
|
|
Tags: tags,
|
2020-02-17 14:56:18 +00:00
|
|
|
Command: "PRIVMSG",
|
2020-04-21 20:54:45 +00:00
|
|
|
Params: []string{upstreamName, unmarshaledText},
|
2020-02-17 15:17:31 +00:00
|
|
|
})
|
2020-03-16 13:28:45 +00:00
|
|
|
|
2020-05-21 05:04:34 +00:00
|
|
|
echoTags := tags.Copy()
|
|
|
|
echoTags["time"] = irc.TagValue(time.Now().UTC().Format(serverTimeLayout))
|
2020-03-17 15:15:54 +00:00
|
|
|
echoMsg := &irc.Message{
|
2020-05-21 05:04:34 +00:00
|
|
|
Tags: echoTags,
|
2020-03-17 15:15:54 +00:00
|
|
|
Prefix: &irc.Prefix{
|
|
|
|
Name: uc.nick,
|
|
|
|
User: uc.username,
|
|
|
|
},
|
2020-03-17 15:17:39 +00:00
|
|
|
Command: "PRIVMSG",
|
2020-03-17 15:15:54 +00:00
|
|
|
Params: []string{upstreamName, text},
|
|
|
|
}
|
2020-04-06 19:42:55 +00:00
|
|
|
uc.produce(upstreamName, echoMsg, dc)
|
Add customizable auto-detaching, auto-reattaching, relaying.
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
2020-11-30 21:08:33 +00:00
|
|
|
|
|
|
|
uc.updateChannelAutoDetach(upstreamName)
|
2020-02-17 14:56:18 +00:00
|
|
|
}
|
2020-03-26 05:20:28 +00:00
|
|
|
case "NOTICE":
|
|
|
|
var targetsStr, text string
|
|
|
|
if err := parseMessageParams(msg, &targetsStr, &text); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-05-21 05:04:34 +00:00
|
|
|
tags := copyClientTags(msg.Tags)
|
2020-03-26 05:20:28 +00:00
|
|
|
|
|
|
|
for _, name := range strings.Split(targetsStr, ",") {
|
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(name)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2020-04-21 20:54:45 +00:00
|
|
|
unmarshaledText := text
|
|
|
|
if uc.isChannel(upstreamName) {
|
|
|
|
unmarshaledText = dc.unmarshalText(uc, text)
|
|
|
|
}
|
2020-05-19 15:27:43 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-05-21 05:04:34 +00:00
|
|
|
Tags: tags,
|
2020-03-26 05:20:28 +00:00
|
|
|
Command: "NOTICE",
|
2020-04-21 20:54:45 +00:00
|
|
|
Params: []string{upstreamName, unmarshaledText},
|
2020-03-26 05:20:28 +00:00
|
|
|
})
|
Add customizable auto-detaching, auto-reattaching, relaying.
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
2020-11-30 21:08:33 +00:00
|
|
|
|
|
|
|
uc.updateChannelAutoDetach(upstreamName)
|
2020-03-26 05:20:28 +00:00
|
|
|
}
|
2020-05-21 05:04:34 +00:00
|
|
|
case "TAGMSG":
|
|
|
|
var targetsStr string
|
|
|
|
if err := parseMessageParams(msg, &targetsStr); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
tags := copyClientTags(msg.Tags)
|
|
|
|
|
|
|
|
for _, name := range strings.Split(targetsStr, ",") {
|
|
|
|
uc, upstreamName, err := dc.unmarshalEntity(name)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2020-11-20 10:19:51 +00:00
|
|
|
if _, ok := uc.caps["message-tags"]; !ok {
|
|
|
|
continue
|
|
|
|
}
|
2020-05-21 05:04:34 +00:00
|
|
|
|
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
|
|
|
Tags: tags,
|
|
|
|
Command: "TAGMSG",
|
|
|
|
Params: []string{upstreamName},
|
|
|
|
})
|
Add customizable auto-detaching, auto-reattaching, relaying.
This uses the fields added previously to the Channel struct to implement
the actual detaching/reattaching/relaying logic.
The `FilterDefault` values of the messages filters are currently
hardcoded.
The values of the message filters are not currently user-settable.
This introduces a new user event, eventChannelDetach, which stores an
upstreamConn (which might become invalid at the time of processing), and
a channel name, used for auto-detaching. Every time the channel detach
timer is refreshed (by receveing a message, etc.), a new timer is
created on the upstreamChannel, which will dispatch this event after the
duration (and discards the previous timer, if any).
2020-11-30 21:08:33 +00:00
|
|
|
|
|
|
|
uc.updateChannelAutoDetach(upstreamName)
|
2020-05-21 05:04:34 +00:00
|
|
|
}
|
2020-03-26 05:03:07 +00:00
|
|
|
case "INVITE":
|
|
|
|
var user, channel string
|
|
|
|
if err := parseMessageParams(msg, &user, &channel); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
ucChannel, upstreamChannel, err := dc.unmarshalEntity(channel)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
ucUser, upstreamUser, err := dc.unmarshalEntity(user)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
if ucChannel != ucUser {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_USERNOTINCHANNEL,
|
2020-08-20 06:48:16 +00:00
|
|
|
Params: []string{dc.nick, user, channel, "They are on another network"},
|
2020-03-26 05:03:07 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
uc := ucChannel
|
|
|
|
|
2020-03-26 03:30:11 +00:00
|
|
|
uc.SendMessageLabeled(dc.id, &irc.Message{
|
2020-03-26 05:03:07 +00:00
|
|
|
Command: "INVITE",
|
|
|
|
Params: []string{upstreamUser, upstreamChannel},
|
|
|
|
})
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
case "CHATHISTORY":
|
|
|
|
var subcommand string
|
|
|
|
if err := parseMessageParams(msg, &subcommand); err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
var target, criteria, limitStr string
|
|
|
|
if err := parseMessageParams(msg, nil, &target, &criteria, &limitStr); err != nil {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: "FAIL",
|
|
|
|
Params: []string{"CHATHISTORY", "NEED_MORE_PARAMS", subcommand, "Missing parameters"},
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
2021-01-04 16:17:35 +00:00
|
|
|
store, ok := dc.user.msgStore.(chatHistoryMessageStore)
|
|
|
|
if !ok {
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: irc.ERR_UNKNOWNCOMMAND,
|
2021-03-04 15:04:30 +00:00
|
|
|
Params: []string{dc.nick, "CHATHISTORY", "Unknown command"},
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
uc, entity, err := dc.unmarshalEntity(target)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2021-03-26 09:17:48 +00:00
|
|
|
entity = uc.network.casemap(entity)
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
|
|
|
|
// TODO: support msgid criteria
|
|
|
|
criteriaParts := strings.SplitN(criteria, "=", 2)
|
|
|
|
if len(criteriaParts) != 2 || criteriaParts[0] != "timestamp" {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: "FAIL",
|
2021-03-04 15:04:30 +00:00
|
|
|
Params: []string{"CHATHISTORY", "INVALID_PARAMS", subcommand, criteria, "Unknown criteria"},
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
timestamp, err := time.Parse(serverTimeLayout, criteriaParts[1])
|
|
|
|
if err != nil {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: "FAIL",
|
2021-03-04 15:04:30 +00:00
|
|
|
Params: []string{"CHATHISTORY", "INVALID_PARAMS", subcommand, criteria, "Invalid criteria"},
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
|
|
|
limit, err := strconv.Atoi(limitStr)
|
|
|
|
if err != nil || limit < 0 || limit > dc.srv.HistoryLimit {
|
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: "FAIL",
|
2021-03-04 15:04:30 +00:00
|
|
|
Params: []string{"CHATHISTORY", "INVALID_PARAMS", subcommand, limitStr, "Invalid limit"},
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
2020-08-11 13:58:50 +00:00
|
|
|
var history []*irc.Message
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
switch subcommand {
|
|
|
|
case "BEFORE":
|
2021-01-04 16:17:35 +00:00
|
|
|
history, err = store.LoadBeforeTime(uc.network, entity, timestamp, limit)
|
2020-07-15 15:47:57 +00:00
|
|
|
case "AFTER":
|
2021-01-04 16:17:35 +00:00
|
|
|
history, err = store.LoadAfterTime(uc.network, entity, timestamp, limit)
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
default:
|
2020-07-15 15:47:57 +00:00
|
|
|
// TODO: support LATEST, BETWEEN
|
Add support for downstream CHATHISTORY
This adds support for the WIP (at the time of this commit)
draft/chathistory extension, based on the draft at [1] and the
additional comments at [2].
This gets the history by parsing the chat logs, and is therefore only
enabled when the logs are enabled and the log path is configured.
Getting the history only from the logs adds some restrictions:
- we cannot get history by msgid (those are not logged)
- we cannot get the users masks (maybe they could be inferred from the
JOIN etc, but it is not worth the effort and would not work every
time)
The regular soju network history is not sent to clients that support
draft/chathistory, so that they can fetch what they need by manually
calling CHATHISTORY.
The only supported command is BEFORE for now, because that is the only
required command for an app that offers an "infinite history scrollback"
feature.
Regarding implementation, rather than reading the file from the end in
reverse, we simply start from the beginning of each log file, store each
PRIVMSG into a ring, then add the last lines of that ring into the
history we'll return later. The message parsing implementation must be
kept somewhat fast because an app could potentially request thousands of
messages in several files. Here we are using simple sscanf and indexOf
rather than regexps.
In case some log files do not contain any message (for example because
the user had not joined a channel at that time), we try up to a 100 days
of empty log files before giving up.
[1]: https://github.com/prawnsalad/ircv3-specifications/pull/3/files
[2]: https://github.com/ircv3/ircv3-specifications/pull/393/files#r350210018
2020-05-21 22:59:57 +00:00
|
|
|
return ircError{&irc.Message{
|
|
|
|
Command: "FAIL",
|
|
|
|
Params: []string{"CHATHISTORY", "UNKNOWN_COMMAND", subcommand, "Unknown command"},
|
|
|
|
}}
|
|
|
|
}
|
2020-08-11 13:58:50 +00:00
|
|
|
if err != nil {
|
|
|
|
dc.logger.Printf("failed parsing log messages for chathistory: %v", err)
|
|
|
|
return newChatHistoryError(subcommand, target)
|
|
|
|
}
|
|
|
|
|
|
|
|
batchRef := "history"
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "BATCH",
|
|
|
|
Params: []string{"+" + batchRef, "chathistory", target},
|
|
|
|
})
|
|
|
|
|
|
|
|
for _, msg := range history {
|
|
|
|
msg.Tags["batch"] = irc.TagValue(batchRef)
|
|
|
|
dc.SendMessage(dc.marshalMessage(msg, uc.network))
|
|
|
|
}
|
|
|
|
|
|
|
|
dc.SendMessage(&irc.Message{
|
|
|
|
Prefix: dc.srv.prefix(),
|
|
|
|
Command: "BATCH",
|
|
|
|
Params: []string{"-" + batchRef},
|
|
|
|
})
|
2020-02-06 15:18:19 +00:00
|
|
|
default:
|
2020-02-17 11:36:42 +00:00
|
|
|
dc.logger.Printf("unhandled message: %v", msg)
|
2020-02-06 15:18:19 +00:00
|
|
|
return newUnknownCommandError(msg.Command)
|
|
|
|
}
|
2020-02-07 11:19:42 +00:00
|
|
|
return nil
|
2020-02-06 15:18:19 +00:00
|
|
|
}
|
2020-03-13 14:12:44 +00:00
|
|
|
|
|
|
|
func (dc *downstreamConn) handleNickServPRIVMSG(uc *upstreamConn, text string) {
|
|
|
|
username, password, ok := parseNickServCredentials(text, uc.nick)
|
|
|
|
if !ok {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2020-05-29 11:10:54 +00:00
|
|
|
// User may have e.g. EXTERNAL mechanism configured. We do not want to
|
|
|
|
// automatically erase the key pair or any other credentials.
|
|
|
|
if uc.network.SASL.Mechanism != "" && uc.network.SASL.Mechanism != "PLAIN" {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2020-03-13 14:12:44 +00:00
|
|
|
dc.logger.Printf("auto-saving NickServ credentials with username %q", username)
|
|
|
|
n := uc.network
|
|
|
|
n.SASL.Mechanism = "PLAIN"
|
|
|
|
n.SASL.Plain.Username = username
|
|
|
|
n.SASL.Plain.Password = password
|
2020-10-24 13:14:23 +00:00
|
|
|
if err := dc.srv.db.StoreNetwork(dc.user.ID, &n.Network); err != nil {
|
2020-03-13 14:12:44 +00:00
|
|
|
dc.logger.Printf("failed to save NickServ credentials: %v", err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func parseNickServCredentials(text, nick string) (username, password string, ok bool) {
|
|
|
|
fields := strings.Fields(text)
|
|
|
|
if len(fields) < 2 {
|
|
|
|
return "", "", false
|
|
|
|
}
|
|
|
|
cmd := strings.ToUpper(fields[0])
|
|
|
|
params := fields[1:]
|
|
|
|
switch cmd {
|
|
|
|
case "REGISTER":
|
|
|
|
username = nick
|
|
|
|
password = params[0]
|
|
|
|
case "IDENTIFY":
|
|
|
|
if len(params) == 1 {
|
|
|
|
username = nick
|
2020-03-28 09:40:33 +00:00
|
|
|
password = params[0]
|
2020-03-13 14:12:44 +00:00
|
|
|
} else {
|
|
|
|
username = params[0]
|
2020-03-28 09:40:33 +00:00
|
|
|
password = params[1]
|
|
|
|
}
|
|
|
|
case "SET":
|
|
|
|
if len(params) == 2 && strings.EqualFold(params[0], "PASSWORD") {
|
|
|
|
username = nick
|
|
|
|
password = params[1]
|
2020-03-13 14:12:44 +00:00
|
|
|
}
|
2020-06-24 19:48:09 +00:00
|
|
|
default:
|
|
|
|
return "", "", false
|
2020-03-13 14:12:44 +00:00
|
|
|
}
|
|
|
|
return username, password, true
|
|
|
|
}
|