Before this, if there was a stream error response by the server to our
stream open, that error response would only be handled in the reader
thread, and the user would get a message like:
"org.jivesoftware.smack.SmackException$NoResponseException: No
response received within reply timeout. Timeout was
5000ms (~5s). While waiting for SASL mechanisms stream feature from
server"
while the server may actually sent something like
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='6785787028201586334'
from='jabbim.com'
version='1.0'
xml:lang='en'>
<stream:error>
<policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
</policy-violation>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Too many (2) failed authentications from this IP
address (1xx.66.xx.xxx). The address will be unblocked at 04:24:00
06.01.2017 UTC
</text>
</stream:error>
</stream:stream>
It was necessary to change saslFeatureReceived from SmackException to
XMPPException in order to return the StreamErrorException at this sync
point. But this change in return required the introduction of a
tlsHandled sync point for SmackException (which just acts as a wrapper
for the various exception types that could occurn when establishing
TLS). The tlsHandled sync point is marked successful even if no TLS
was established in case none was required and/or if not supported by
the server.
The pattern
if (now > deadline) break;
wait(deadline - now);
is insufficient in case "now == deadline" because the result would be
wait() being called with 0, which would mean "wait until
notified". Thus, the timeout would become infinite.
This adds the ability to provide a distinct authorization identifier for use
by SASL mechanisms. Not all SASL mechanisms support this operation, in
particular CRAM-MD5.
Both the javax and provided SASL implementations are extended, and an authzid
parameter added to the authenticate method.
The authorization identifier is passed as a EntityBareJid in order to assure the
correct form.
Resolves SMACK-677.
Minor-Modifications-By: Florian Schmaus <flo@geekplace.eu>
Instead of extending SocketFactory, the proxy support classes now
implement ProxySocketConnection. This removes a lot of unnecessary
code.
Also re-enables proxy support, which was broken in previous versions
because none of extended SocketFactories did override
createSocket() (SMACK-683).
Add
- performSaslAnonymousAuthentication()
- performSaslExternalAuthentication(SSLContext)
- addEnabledSaslMechanism(String)
- addEnabledSaslMechanisms(Collection<String>)
to ConnectionConfiguration.Builder.
Instead of providing a special API call for anonymous authentication,
Smack now has a configuration builder method to set anonymous/external
authentication. This also removes a lot of duplicate code within
Smack.
Also move SASLAnonymous into o.j.smack.sasl.core.
Fixes SMACK-629.
and remove getConnectionID().
Also make streamId a field of AbstractXMPPConnection. Most XMPP
connection types have a streamId, it appears to be optional when BOSH
is used though.
Replace SaslException with SmackException in XMPPBOSHConnection, that is
the exception which is used in XMPPTCPConnection for the same purpose.
Also make androidProjects a multi-line list.
to avoid confusion between the IQ element 'iq' and the IQs child
element. ELEMENT defined in an IQ sublcass should contain the *child*
element.
Add element to StreamInitation and fix FileTransferManager which still
used a packet listener instead of an IQ request handler to handle
incoming stream initiation requests.
Differentiate between asynchronous and synchronous ones. Asynchronous
are the ones where the invocation order may not be the same as the order
in which the stanzas arrived.
Since it's no longer guaranteed that when a unit test calls
processPacket(stanza)
the stanza will be completely processed when the call returns, it was
necessary to extend the unit tests (mostly Roster and ChatManager) with
a packet listener that waits for his invocation. Since we now also use
LinkedHashMaps as Map for the packet listeners (SMACK-531, SMACK-424),
adding a packet listeners as last also means that it will be called as
last. We exploit this behavior change now in the unit tests.
Rename 'recvListeners' to 'syncRecvListeners' in AbstractXMPPConnection.
Rename 'rosterInitialized' to 'loaded' in Roster.
Add Roster.isLoaded().
Reset 'loaded' to false in
Roster.setOfflinePresencesAndResetLoaded() (was setOfflinePresences()).
Fixes SMACK-583, SMACK-532, SMACK-424
In dd84d53bbc the usage of dynamic
dependencies was removed because OSS Sonatype would not longer allow
them, i.e. the '1.2.+' notation, on release artifacts. But they allow
the mathematical range notation '(1.2,1.3]', therefore we use this now.
Introducing a clean split between the constant connection configuration
parameters, which are now all in ConnectionConfiguration and the dynamic
connection state (e.g. hostAddresses) which are now in
AbstractXMPPConnection.
Also removed all arguments of login() since the username, password,
resource and callback handler need now to be configured via
ConnectionConfiguration.
Also remove documentation/extensions/messageevents.md, as it's already
in documentation/legacy
sendListeners are now invoked *after* the packet has been put on the
wire.
Also sending listener exceptions are not catched and not only
NotConnectedExceptions. And a exception does not cause a 'break' but a
'continue' now. Log level is WARNING now.
so that APIs that need a fully connected but not yet authenticated
connection (e.g. AccountManager) can use the connection after connect()
returns.
Also move "connected = true" after saslFeatureReceived check, as if the
check would throw, the boolean would still be 'true' resulting in an
inconsistent state.
Otherwise this could result in
D/SMACK﹕ SENT (12): <stream:stream xmlns='jabber:client' to='*server*' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
D/SMACK﹕ SENT (12): <iq id='miS03-37' to='*server*' type='get'><query xmlns='jabber:iq:register'></query></iq>
D/SMACK﹕ RCV (12): <?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='4280133582' from='*server*' version='1.0' xml:lang='en'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>PLAIN</mechanism><mechanism >DIGEST-MD5</mechanism><mechanism>SCRAM-SHA-1</mechanism></mechanisms><c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://www.process-one.net/en/ejabberd/' ver='a4WL1hRFRX38OouQz3okC+ayK2o='/><register xmlns='http://jabber.org/features/iq-register'/></stream:features>
D/SMACK﹕ SENT (12): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'></starttls>
D/SMACK﹕ RCV (12): <iq from='*server*' id='miS03-37' type='result'><query xmlns='jabber:iq:register'><instructions>Choose a username and password to register with this server</instructions><username></username><password/></query></iq>
D/SMACK﹕ SENT (12): <iq id='miS03-39' to='*server*' type='set'><query xmlns='jabber:iq:register'><password>s0r73pgojeopmssjaairu6kcmk3v4l</password>< username>nqcjloj4v6uk52bug16hrrhspfanlr</username></query></iq>
D/SMACK﹕ RCV (12): <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
W/AbstractXMPPConnection﹕ Connection closed with error
javax.net.ssl.SSLException: Connection closed by peer
at com.android.org.conscrypt.NativeCrypto.SSL_do_handshake(Native Method)
at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.ja va:405)
at com.android.org.conscrypt.OpenSSLSocketImpl$SSLInputStream.<init>(OpenSSLSocket Impl.java:661)
at com.android.org.conscrypt.OpenSSLSocketImpl.getInputStream(OpenSSLSocketImpl.ja va:632)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.initReaderAndWriter(XMPPTCPConnect ion.java:661)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnecti on.java:768)
- De-duplicate code by moving it into AbstractXMPPConnection
- Introduce TopLevelStreamElement as superclass for all XMPP stream elements.
- Add SynchronizationPoint, ParserUtils
- Add ParserUtils
Fixes SMACK-333 and SMACK-521
also remove faulty PongFilter from PingManager. It never matched any
stanzas, since a Pong is just a plain result IQ that is not qualified by
any XMPP Ping namespace.
Fixes SMACK-597
This commit marks an important milestone with the addition of the
smack-android subproject. Smack is now able to run native on Android
without requiring any modifications, which makes the aSmack build
environment obsolete.
It was necessary to redesign the code for SASL authentication to achieve
this. Smack now comes with smack-sasl-provided for SASL implementations
that do not rely on additional APIs like javax for platforms where those
APIs are not available like Android.
Move some duplicate code from XMPP(TCP|BOSH)Connection to
PacketParserUtils. Remove TestUtils as the method now part of Smack's
public API in PacketParserUtils.
Because of OSGi, no subproject of Smack (which is the same as a OSGi
bundle) must export a package that is already exported by another
subproject.
Therefore it was necessary to move the TCP and BOSH code into their own
packages: org.jivesoftware.smack.(tcp|bosh).
OSGi classloader restrictions also made it necessary to create a
Declarative Service for smack-extensions, smack-experimental and
smack-lagacy (i.e. smack subprojects which should be initialized), in
order to initialize them accordingly, as smack-core is, when used in a
OSGi environment, unable to load and initialize classes from other smack
bundles. OSGi's "Service Component Runtime" (SCR) will now take care of
running the initialization code of the particular Smack bundle by
activating its Declarative Service.
That is also the reason why most initialization related method now have an
additional classloader argument.
Note that due the refactoring, some ugly changes in XMPPTCPConnection
and its PacketReader and PacketWriter where necessary.
instead of using the old baseName=smack appendix=project.name approach,
we are now going convention over configuration and renaming the
subprojects directories to the proper name.
Having a prefix is actually very helpful, because the resulting
libraries will be named like the subproject. And a core-4.0.0-rc1.jar is
not as explicit about what it actually *is* as a
smack-core-4.0.0-rc1.jar.
SMACK-265
