| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This is where 64ddcbc9a328 should have started. By preventing creation
of users with invalid JIDs, it will slowly become safer to enforce
strict validation on everything.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This should prevent any MUCs with invalid JID (according to current normalization routine)
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Intended to be for HTTP-ish numeric status codes
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
valid remote JIDs that aren't valid under STRINGPREP / Unicode 3.2
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Be conservative in what you let your clients send, be liberal in what
you let in via s2s.
Being strict on s2s leads to interop problems and poor experiences, ie
users being ejected from MUCs if something invalid enters. By starting
with tightening up input into the network, we may be able to gradually
approach a point where no invalid JIDs are allowed.
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This is to prevent mistakes like nodeprep(username:gsub("a","b")) from
unintentionally invoking strict mode.
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
(fixes #1455)
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
This takes advantage of data type validation and conversion done in util.dataforms.
|
| | | | | | | | | | |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
Committed by Zash
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| | | |\ \ \ \ \ \ \ |
|
| | | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
XEP-0268
|
| | | | | | | | | | | |
|
| | | | | | | | | | | |
|
| | | |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
This gets printed before TLS if c2s_require_encryption = false,
in which case it is just annoying.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
This makes sets of excluded mechanisms easily available for use later.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
> Server support of XEP-0368 means having the ability to accept direct TLS connections.
This is what legacy_ssl_ports does. First trace of it seems to be 8458be0941e7
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
mod_csi_simple tries to follow the advice in XEP-0268.
Notably, since 7d78b24d8449 it also does this:
> If the server receives data, the phones radio is already on, therefore
> you should flush any pending data as soon as possible after receiving
> data from a client
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Fairly useless to only log half of SASL messages.
Use mod_stanza_debug instead to get the full exchange.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Might come out of :getpeername different later but at least it's something.
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
Since they may have been unknown when the connection was created.
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
These will sometimes return nil, "Transport not connected" but not throw
a hard error. This shouldn't be treated as success.
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
A Direct TLS connection (eg HTTPS) gets turned into a LuaSec handle
before the :updatenames call done in the :connect method. LuaSec does
not expose the :getpeername and :getsockname methods, so the addresses
remain obscured, making debugging trickier since the actual IP addrerss
connected to does not show up.
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
It was weird that it said "Prepared to start TLS" before "Client .. created"
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
BC: This overloads the GET event.
Previous commit ensures HEAD requests are sent without a body.
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|
| | | | | | | | | | | | |
|