| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This allows us to store a time, actor, comment and/or reason why an account
was disabled, which seems a generally useful thing to support.
|
| |
|
|
|
|
| |
initialization
|
|
|
|
| |
Everything supports SNI today, so this is not useful information.
|
|\ |
|
| |
| |
| |
| | |
A typo should not result in ending up with "legacy"
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Unlikely that anyone has had sql2 in their configs for a long time, so
this serves little purpose.
Leaving the indirection function in case some similar compat code is
needed in the future.
|
| |
| |
| |
| |
| |
| |
| | |
Improves readability. Reduces line count. What's not to like?
The code style and luacheck rules allows longer lines, and these strings
aren't long enough to need breaking into multiple lines like this.
|
| |
| |
| |
| |
| |
| | |
Since 443 is just as much a web port as port 80 these days, if not more.
What's with port 81 here?
|
| |
| |
| |
| |
| | |
Allows specifying them the same way as the default and in the config,
for consistency
|
| |
| |
| |
| | |
Maybe these should live in util.mathcompat?
|
| |
| |
| |
| |
| |
| | |
To match :get_option_number etc, specifying the allowed interval.
Default is essentially (0, inf].
|
| |
| |
| |
| |
| |
| |
| | |
Many options in Prosody that are treated as numbers don't make sense as
floats, e.g. sizes and limits measured in bytes.
Simplified implementation based on an earlier attempt dating back to 2020
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
As a way to signal that the periodic thing should be disabled, matching
existing mod_mam usage
|
| |
| |
| |
| |
| | |
Pass positive numbers trough unharmed, parse strings as periods, discard
anything else.
|
| |
| |
| |
| |
| | |
E.g. for use in mod_mam and others that take an amount of time before
some (usually cleanup) action is taken.
|
| | |
|
| |
| |
| |
| | |
For when a setting has a few fixed values it can take
|
|\| |
|
| |
| |
| |
| | |
Ref https://github.com/mozilla/server-side-tls/issues/285
|
| |
| |
| |
| |
| |
| |
| | |
This gives us more granular control over different types of user account.
Accounts registered by IBR get assigned prosody:registered by default, while
accounts provisioned by an admin (e.g. via prosodyctl shell) will receive
prosody:member by default.
|
| | |
|
| |
| |
| |
| |
| | |
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.
|
| |
| |
| |
| |
| | |
Further isolates LuaSec from Prosody core, with the ultimate goal of
allowing LuaSec to be replaced more easily.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Could be used to implement custom connection methods (c.f. mod_onions)
without needing to duplicate the rest of route_to_new_session().
Adds a feature to enable detection since it can be difficult to detect
support for an event otherwise.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Closing the session invokes ondisconnect and session close logic,
including mod_smacks hibernation and the timer that destroys the session
after a timeout.
By closing the connection after it has been detached from the sessions
table it will no longer invoke the ondetach handler, which should
prevent the above problem.
|
| |
| |
| |
| |
| | |
This is a convenience function, and there is currently no module-specific code
required to implement it. Not using 'self' is to be expected.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is a common pattern for modules to do something like check for
prosody.start_time, and execute code immediately if it is present, or wait for
the server-started event if it isn't yet. For example, this allows you to run
code after all other modules/hosts have been loaded, that are going to be
loaded.
Such code can now be replaced with a simple call to this method.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current method logs scary "access denied" messages on failure - this is
generally very useful when debugging access control stuff, but in some cases
the call is simply a check to see if someone *could* perform an action, even
if they haven't requested it yet. One example is determining whether to show
the user as an admin in disco.
The 'peek' parameter, if true, will suppress such logging.
The :could() method is just a simple helper that can make the calling code a
bit more readable (suggested by Zash).
|
| |
| |
| |
| |
| |
| |
| | |
We expect every session to explicitly have a role assigned. Falling back to
any kind of "default" role (even the user's default role) in the absence of
an explicit role could open up the possibility of accidental privilege
escalation.
|
| |
| |
| |
| | |
Spaces, no hyphen, apparently.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
This combines the two most common store types, which modules often end up
opening with both interfaces separately anyway.
As well as combining them, I've taken the opportunity to improve some of the
method names to make them clearer.
|
| |
| |
| |
| | |
Allows modules explicit dependencies upon its availability
|
| |
| |
| |
| |
| | |
Useful to know why a module was auto-loaded without having to dig trough
all other modules for the one that depends on it.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Some of the OAuth stuff highlights a small need to retrieve a list of
roles somehow. Handy if you ever need a role selector in adhoc or
something.
Unless there's some O(n) thing we were avoiding?
|
| |
| |
| |
| | |
Allow modules to act on this state change, e.g. kick accounts etc.
|
| |
| |
| |
| | |
Calling into the auth module, where available.
|
|\| |
|
| | |
|
| |
| |
| |
| |
| | |
If it reaches this point, then the session will be most definitely be
destroyed, so try to prevent destroy_session() from being called again.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On regular disconnects, </stream> is sent, then
sessionmanager.destroy_session() is called, then
sessionmanager.destroy_session() is called again when the TCP connection
is closed, from ondisconnect in mod_c2s.
It is a bit annoying and doesn't really tell you much.
|
| | |
|
| |
| |
| |
| |
| | |
This allows for modules to update fields, which is generally better than
maintaining this hard-coded list of transferable properties here.
|