Age | Commit message (Collapse) | Author |
|
This allows applications to filter out sensitive information, such
as passwords, so that it won't appear in the logs.
It does mean that the debug logs will not show the actual received
data, and there will be no indication of tampering, unless the
filter author explicitly logs and notes that a change was made.
|
|
|
|
|
|
forms.
|
|
The item fields were not setting their type based on the reported
field's type attribute, so values were not being encoded properly.
Fixes issue #121
|
|
|
|
A filter accepts and returns a stanza, but potentially modified.
To prevent sending/receiving a stanza, a filter may return None.
Incoming:
self.add_filter('in', in_filter)
Outgoing:
self.add_filter('out', out_filter)
Filters are applied in the order thay are added. However, you may
add an order parameter, which is the place in the list to insert the
filter:
self.add_filter('in', in_filter, order=0)
|
|
Only allowing handlers to return a DiscoInfo/DiscoItem stanza works
for the majority of cases, but does not allow for the addition of
an RSM stanza, or other extensions.
An Iq stanza returned by a handler must already be configured as
a reply.
|
|
|
|
If an iterable plugin was an enabled, it wasn't added to
the iterables list.
|
|
|
|
May set self.disconnect_wait=True so that all disconnect
calls wait for the send queue to empty, unless explicitly
overridden with wait=False.
The session_end now fires before closing the socket so
that final stanzas may be sent, such as unavailable presences
for components.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The form plugin was being registered on first use for providers,
but not for clients receiving the form.
NOTE: Use of non-form payloads will have this issue - adhoc command
clients will need to have an expectation beforehand of what
the command payload will be to properly load stanza plugins.
|
|
Fixes issue #118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Calling reconnect() simultaneously from multiple threads (like when
using XEP-0199 keepalive) could break because the connection state
can transition and break the state expectations in one of the
reconnect() calls.
|
|
This may need to be reverted if CTRL-C handling breaks, but everything
works fine so far in testing.
Resolves issue #95.
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
examples/ping.py
sleekxmpp/basexmpp.py
sleekxmpp/clientxmpp.py
sleekxmpp/features/feature_bind/bind.py
sleekxmpp/features/feature_mechanisms/mechanisms.py
sleekxmpp/plugins/gmail_notify.py
sleekxmpp/plugins/jobs.py
sleekxmpp/plugins/xep_0009/remote.py
sleekxmpp/plugins/xep_0009/rpc.py
sleekxmpp/plugins/xep_0012.py
sleekxmpp/plugins/xep_0045.py
sleekxmpp/plugins/xep_0050/adhoc.py
sleekxmpp/plugins/xep_0078/legacyauth.py
sleekxmpp/plugins/xep_0085/chat_states.py
sleekxmpp/plugins/xep_0199/ping.py
sleekxmpp/plugins/xep_0224/attention.py
sleekxmpp/xmlstream/handler/waiter.py
sleekxmpp/xmlstream/matcher/xmlmask.py
sleekxmpp/xmlstream/xmlstream.py
Conflicts:
examples/ping.py
sleekxmpp/basexmpp.py
sleekxmpp/clientxmpp.py
sleekxmpp/features/feature_bind/bind.py
sleekxmpp/features/feature_mechanisms/mechanisms.py
sleekxmpp/plugins/gmail_notify.py
sleekxmpp/plugins/jobs.py
sleekxmpp/plugins/xep_0009/remote.py
sleekxmpp/plugins/xep_0009/rpc.py
sleekxmpp/plugins/xep_0012.py
sleekxmpp/plugins/xep_0045.py
sleekxmpp/plugins/xep_0050/adhoc.py
sleekxmpp/plugins/xep_0078/legacyauth.py
sleekxmpp/plugins/xep_0085/chat_states.py
sleekxmpp/plugins/xep_0199/ping.py
sleekxmpp/plugins/xep_0224/attention.py
sleekxmpp/xmlstream/handler/waiter.py
sleekxmpp/xmlstream/matcher/xmlmask.py
sleekxmpp/xmlstream/xmlstream.py
|
|
|
|
|
|
~ 15% of CPU on moderate load.
|
|
|
|
computing logging data that may never be used. This is a HUGE performance improvement; in some of my test runs, unnecessary string creation was accounting for > 60% of all CPU time.
Note that using % in a string will _always_ perform the sting substitutions, because the strings are constructed before the function is called. So log.debug('%s' % expensiveoperation()) will take about the same CPU time whether or not the logging level is DEBUG or INFO. if you use , no substitutions are performed unless the string is actually logged
|
|
computing logging data that may never be used. This is a HUGE performance improvement; in some of my test runs, unnecessary string creation was accounting for > 60% of all CPU time.
Note that using % in a string will _always_ perform the sting substitutions, because the strings are constructed before the function is called. So log.debug('%s' % expensiveoperation()) will take about the same CPU time whether or not the logging level is DEBUG or INFO. if you use , no substitutions are performed unless the string is actually logged
|
|
|