| Age | Commit message (Collapse) | Author |
|---|
|
Adds functionalities for URL processing such as extracting parameters from URL, decoding URL.
License:
This patch is BSD-licensed, see Documentation/Licenses/BSD-simplified.txt for details.
Test-Information:
Corresponding tests are added for each function which passes.
Change-Id: I1d54b86167b4f368c365f16c63641a6e6a91cbb8
|
|
Adds the Simple ID Generator as well as Random ID Generator.
License:
This patch is BSD-licensed, see Documentation/Licenses/BSD-simplified.txt for details.
Test-Information:
Tests added for both IDGenerator and SimpleIDGenerator which passes.
Change-Id: I9bce3a172774effead3ada695bcceb0b0f81b851
|
|
There was a bug with stroke where if I sent a large amount of messgaes (cica
1000) and then disconnected, not all the messages would be sent before storke
handled the disconnect. It seems it did not fully lear the write buffer before
closing the stream.
This patch shoudl fix the error. It now only closses if the disconnecting flag
is closed and the write buffer is closed. This should bring it into line with
Swiften behaviour.
Test-information:
I had a simple stroke application that sent 1000 messages and then disconnected.
Before the patch it would only send abut 80 or so of the messages before it got
disconnected. After the patch it now sends all the messages before
disconnecting.
Change-Id: I6f56b25dcbabd16ee860dbf353f39559a77d6830
Signed-off-by: Alex Clayton <alex.clayton@isode.com>
|
|
The recent change introducing the DiscoInfoResponder didn't initialise the member variable, leading to crashes in Stroke.
Test-Information:
Blind
Change-Id: I1b9de02fae82990db3882c8f1d58cca76555944e
|
|
Change-Id: I005c81cd04f1e6b2ea5145ca914fae3a02515ae5
|
|
Change visibility of some methods in SecurityLabel &
SecurityLabelsCatalog and provide default values for strings and
collections in those clases.
Change-Id: I1ea3f6b20deac1d1ac7999dd304e2e755d5e7c8a
|
|
JavaConnection.disconnect() can be called at any time when opening or
using the connection. Its use can interfere with tests for
selector_.isOpen(). Protect relevant code by synchronization blocks.
This should not cause any contended synchronization issue as contention
can only occur while disconnecting. This reverts the relevant part of
7d2101b9.
Move selector_.select() call to end of Worker.run() while loop so that
any write that is done while still connecting (if that is permitted and
possible), and before selector_ first become non-null, is still picked
up.
Remove redundant checks on disconnecting_ and calls to
handleDisconnected(null).
Move a couple of fields which are only used in Worker nested class into
Worker.
Update copyright.
Change-Id: I2eabad79c69fe4e9206942c8025e0ac012bffdb0
|
|
The code is currently doing
bytesConsumed += lastConsumed;
inside one of the clauses in a while loop, and then the same operation
again when the while loop exits. So there is a risk that the
"bytesConsumed" value will be too large.
In fact the only place the value of "bytesConsumed" is used is by some
code that checks whether it's greater than zero, so it would not be
problematic if the value were too large.
It seems worth fixing this in case future changes rely on the
"bytesConsumed" value being accurate.
Test-information:
inspection only
Change-Id: Ibd6fd01417afc4c4e030a5173bfba9a02980a757
signed-off-by:robert.williams@isode.com
|
|
Change-Id: I4ec639aba4eb60d0bc1e25f2d86f17592f819d64
|
|
Change-Id: Id919d64f05964e5cb5657d22c7eaf6ae7199bb7a
|
|
Change-Id: I3578fa59bfcb45f5893a16fa2d45c9ea460be198
|
|
Change-Id: I5ae22fee5a68a7a5d3575a576fb6eb490487c171
|
|
MemoryStorages, Storages
NickManager, NickResolver
CryptoProvider, Hash, SafeByteArray, JavaCryptoProvider
CapsInfoGenerator, CapsManager, CapsMemoryStorage, CapsProvider,
CapsStorage, CapsInfo
CapsInfoSerializer, CapsInfoParser
ClientDiscoManager, DiscoInfoResponder, EntityCapsManager,
EntityCapsProvider
GetDiscoInfoRequest
ChatState, Idle
Presence, PayloadAddingPresenceSender, PresenceOracle,
SubscriptionManager
StatusSerializer, StatusShowSerializer, StatusParser, StatusShowParser,
Replace, ReplaceParser, ReplaceSerializer
SecurityLabel, SecurityLabelsCatalog, GetSecurityLabelsCatalogRequest
VCard, GetVCardRequest, SetVCardRequest, VCardManager,
VCardMemoryStorage, VCardStorage
RosterMemoryStorage, RosterPushResponder, RosterStorage,
SetRosterRequest
XMPPRoster, XMPPRosterController, XMPPRosterImpl, XMPPRosterItem
GetRosterRequest, SetResponder
Add parsers and serializers for Idle, VCard, PrivateStorage & Stroage.
Add
parser for Subject.
Add impromptu flag to MUCInvitation.
Update copyrights.
Change-Id: I9949f506b70e60b3a64f1dadde8f9b235b322e1d
|
|
Change-Id: I97fa434712eb32ad2c56558434a09fe5b1e3fb92
|
|
Default Locale is unsafe as one could, for example, get Arabic numerals
instead of ASCII ones.
Change-Id: Ib70d271bf433c4928accca3b4802c3ba3cb2aa0e
|
|
Adds the Element, Parser, Serializer, ChatStateTracker and ChatStateSerializerTest.
License:
This patch is BSD-licensed, see Documentation/Licenses/BSD-simplified.txt for details.
Test-Information:
Ported serializer test from Swiften, which passes.
Change-Id: I314eda2db0f2be0499f8aa74d043319fb5cf57a8
|
|
License:
This patch is BSD-licensed, see Documentation/Licenses/BSD-simplified.txt for details.
Change-Id: Ie60e3c22f14a0495912ed02f9d994b93a04e2aec
|
|
Adds the Element, Parser, Serializer and CapsInfoSerializerTest.
License:
This patch is BSD-licensed, see Documentation/Licenses/BSD-simplified.txt for details.
Test-Information:
Ported serializer test from Swiften, which passes.
Change-Id: Iefc10f49732c835f1f17e5da00dabed899da975e
|
|
Android Lollipop implementation reports this
innaccurately during handshaking, which was
causing SSL setup to fail. Now derives the
information directly from ByteBuffer positions.
This change is based on a similar change for Jetty at
https://gist.github.com/tavianator/96e9daab0fd1a45f11f2/8cbbfe028c97cac63d3b39f575b2c317d7a174c2
Test-information:
Tested Harrier with IMAPS and STARTTLS against MBox on Android
4.4 and 5.0 emulators, all connect and authenticate OK.
Tested MLC on Linux, with extra debugging added - everything works,
and the values returned for "lastConsumed" are the same as those
returned by "bytesConsumed()" so the change appears to make no
difference to behaviour for non-Android
Ran unit tests - no failures.
Change-Id: I54b3850136b35535918b0eb303409232d64a60b5
Reviewer: Nick Hudson <nick.hudson@isode.com>
|
|
This operation should be valid according to
Javadocs, but triggers a crash on Android Lollipop:
https://code.google.com/p/android/issues/detail?id=80785
This workaround avoids the crash, and should not
affect behaviour for all other versions.
Test-information:
Forced disconnect on Lollipop, didn't see crash.
Tested MLC with deliberately dropped connections; seems to work as expected.
Change-Id: Ia08476266dd92c40bea04076b3c3d8750737c309
Reviewer: Nick Hudson <nick.hudson@isode.com>
|
|
Change to mirror Swiften code. This change removes some unnecessary code from
the FormSerializer class. It also includes changes to the FormField class to
improve the handling of 'unknown' form fields.
Test-information:
Tested using updatedJUnit tests, all tests complete successfully.
Change-Id: Ie28ed40be976704170525f7be20b8e08661536b6
|
|
MAMFinSerializer should be in the FullPayloadSerializerCollection
Test-information:
Unit test still pass.
Change-Id: Id4b57373860fba48ce2d90d546cb3215952dcc12
|
|
Some patches for MAM had gone into swiften without being ported to stroke. This patch should bring stroke
update to date with Swiften.
The swiften patches in question are
9b762e1cf26cfe12cf601d9ea95cf91b3f95c799 -- Add node attribute to MAMQuery
8096f80861667381b777af774cfd446d6fc8cda8 -- Brining XEP-0313 (MAM) implementation in line with version 3.0.
Test-information:
Ran the updated JUnit tests in Eclipse they all passed ok.
Ran make and make test in a stroke checkout. Everything build ok and the JUNit tests passed.
Change-Id: I95bf5d598808f48fe2d7af12c0f07d852d68c115
|
|
Changes to catch up with Swiften changes to FormField in commit 00284e5,
also adds <reported/> and <item/> elements, added to Swiften in commit 83afa3d.
Changes include refactoring of the FormField class, changes to Form parser
and serializer classes and updates to JUnit tests.
Test-information:
Tested using updated JUnit tests, all tests complete successfully.
Change-Id: Ic91ad4a11a335fb3d2b2a2c4a1865f836e2af70b
Reviewer: Alex Clayton <alex.clayton@isode.com>
Reviewer: Gurmeen Bindra <gurmeen.bindra@isode.com>
|
|
The JavaConnection code which reads from a socket detects a socket
closure and emits a disconnected signal.
It was noticed that on some occasions, data was arriving on the socket
just before it was closed, and this data was never passed to the
application.
This happens when the server writes e.g. a "BYE" message and closes
the socket straight away: when JavaConnection is woken to read the
message, it does so and then goes on to notice that the connection has
been closed and throws an IOException without passing the message back
to the application.
This patch fixes the problem by making sure that any data read prior
to the close being noticed is sent to the application before the closed
signal is emitted
Test-information:
It was possible to provoke the problem by deliberately breaking socket
connections - if you do this often enough you see cases where data
read from the socket is lost.
After this patch, such cases do not result in data loss.
Also tested with email client and verified that connections to
icloud.com which previously had provoked this problem when
authentication failed now seem to return all data reliably.
Change-Id: Ieba0f4186b7c91e55f5f1a4b3b64bc923006b933
|
|
The java code was never emitting the onDataWritten signal, although
the corresponding C++ code in Swiften does do this.
This change causes the signal to be emitted whenever a data is
successfully written to the socket.
Test-information:
Tested using an application which was registering for the signal;
previously it never saw "onDataWritten"; now it does.
Tested using an application which doesn't register for the signal; it
works as before.
Change-Id: I1399af0721ef8226c0c4d2420bbe23f53ad3494f
|
|
The POODLE vulnerability means that using SSLv3 is insecure. So this
change removes it from the list of protocols that JSSEContext may use.
Oracle's "Java Cryptography Architecture Standard Algorithm
Name Documentation"
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html
Lists the "standard names" that can be used in this context:
SSLv2
SSLv3
TLSv1
TLSv1.1
TLSv1.2
SSLv2Hello
After this patch, only the three "TLS" protocols will be allowed.
Test-information:
Tested using JRE6 and JRE7; viewing the SSL handshake indicates that
the protocol being requested is being used when the handshake occurs
Change-Id: I99710a72a4b8567226b1205fdf64c6c67ccc2a9a
|
|
Add a SubjectSerializer to Stroke.
Test-information:
Created a Message object and set its subject. Subject field now turns up in the XMMP telemetry.
Change-Id: I7b310d6dc52852e5704696e5e3762bed6a4d53ad
|
|
This patch updates Stroke as per the Swiften code to get peerCertificate chain.
Test-information:
tested using M-Link Console (XMPP client) to look at the certificate and chain
Change-Id: I2662511b72f9ca6d176a9f4c1e02d10b5df5d2c7
|
|
Until now, Stroke would not do trust anchor checking because there was
no suitable way to getting to a default trust store.
This patch makes stroke use JDK's default trust store for looking up
trust anchors. If it can find the trust anchor in JDK's store, it
proceeds to do validy check. If any check fails, an error is set
and it is upto the client to decide if client is happy with certificate.
Test-information:
I tested with with an XMPP client MLC.
I got prompted with cert for server whose CA was not in Java Trust Store.
After adding the CA to JDK trust store, no prompt was seen
I then renewed the certificte with validity = 2 minutes.
On doing a connection, MLC prompted me because the certificate was expired
even though the CA was in the trust store.
Change-Id: Id3fc86d85641f07814ff8621b8bf038cde406063
Reviewer: Nick Hudson <nick.hudson@isode.com>
Reviewer: Kevin Smith <kevin.smith@isode.com>
|
|
Corresponds to the Swiften change of the same name, d949d1638c
Test-information:
Unit tests pass. Verified that the new code works as expected in
a test application that previously would never see timeouts.
Change-Id: I95cc73a81e42d6ac00c79f74531e8dd6c67882f3
|
|
Since the initial Stroke TLS implementation was done, some changes
were made in Swiften, starting with
"Show Certificate dialog from certificate error window."
159e773b156f531575d0d7e241e2d20c85ee6d7cA
which mean that certificate verification uses the peer's certificate
chain, and not just the peer's EE certificate.
This change updates Stroke so that its API now more closely matches
what Swiften does.
Note that any current Stroke clients that implement the
"CertificateTrustChecker" interface will break, as this patch makes an
incompatible change to that interface, requiring implementing classes
to handle a certificate chain rather than a single certificate.
Isode copyright notices are updated; Remko copyright notices are
updated to reflect the current copyright notices in any equivalent
Swiften source files.
Test-information:
Used MLC (after having patched it for CertificateTrustChecker changes)
and verified that it sees the entire certificate chain coming back.
Ran self-tests for Stroke and saw no junit failures
Change-Id: I3d863f929bfed3324446cadf3bb4d6b9ff916660
|
|
Before this patch, some classes used their own private functions for date time functions.
This patch makes them use the one from DateTime class.
Test-information:
junits pass
Change-Id: I1330c55fbf65205516d6847e4655992ad817fbc4
|
|
The class IQRouter has a private "jid_" field that was not being
initialised to contain an invalid JID, which meant that there was a
risk of NullPointerException if anyone called the "getJID()" method
and tried to use the returned JID.
This showed up because one of the unit tests was getting a
NullPointerException, which caused the failure:
[junit] Test com.isode.stroke.queries.requests.GetPrivateStorageRequestTest FAILED
The failure was shown to have been introduced by the change "Check
sender on incoming IQ responses"
(535e1a979a164f807aa64bf2df2bb36e7015ff17)
This change fixes the initialisation. The other fields in this class
are always initialised so can never be null.
Test-information:
After this patch, unit tests no longer show the failure.
Change-Id: Idfcabf5393c8353194dddc414d58c37301487908
|
|
Import the class SimpleEventLoop from Swiften into Stroke. This also involves renaming the current
SimpleEventLoop class to ImmediateEventLoop
Test Information:
By code inspection.
Change-Id: Ie108a7b3ff98bb078cdd0017f4536e8bd9b76956
Signed-off-by: Alex Clayton <alex.clayton@isode.com>
|
|
Change-Id: I4e5368f9ac86446b7ebf976e2cb63d64ebefe7b2
|
|
The Connector class had "_xmpp-client._tcp." hard-coded in it, which
meant that it was not suitable for non XMPP clients.
This change means that Connector could now be used by clients who are
interested in arbitrary SRV records; the CoreClient class is updated
accordingly.
Test-information:
Built and tested using MLC.
Also tested with a client that is interested in IMAP SRV records
Change-Id: Ia23c148fd8afdd7b3271c47b1c96d086d57a44bd
|
|
Change-Id: Ie8ca77ba8dbcd83926d46307ad0e73d804ff7422
|
|
This patch corresponds with the Swiften commit
5f1cb0d768265347bc80862c33f5967f07759b10 whose comment reads
Release-Notes: Fixed a bug whereby the sender of an iq wasn't being
checked before matching it to a request.
Note that since the Swiften change, other modifications have been made
to the affected files, and these modifications are not reflected in
this patch.
Test-information:
Code builds. Ran with MLC to make sure things all seem to work OK.
Change-Id: Ife96925d4d728bc0fe749d6b5b849fbe4e866315
|
|
Old code was casting Object[] to String[], which may be safe,
but is dependant on the Set's internal implementation of
toArray, and may lead to ClassCastExceptions. We now
preallocate a String[] to avoid the cast and force type
safety for any implementation.
Test-information:
Was crashing when enabling restricted ciphers on Android. Now
works OK.
Change-Id: I759a369449296f1819e91a25aa123b083ec280c9
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
A recent change made Stroke use the dnsjava library instead of JNDI for
domain service queries, because JNDI had problems with IPv6 addresses.
The change also replaced the use of Java's standard InetAddress class for name
resolution with the Address class inside dnsjava - this change was not neccessary, and
is problematic because although the documentation for "Address" says that it "Includes functions
similar to those in the java.net.InetAddress class", it does not provide equivalent functionality.
Specifically, whereas InetAddress.getAllByName() will use the local system's
"host" file when attempting to resolve hostnames, the corresponding Address.getAllByName() method
in dnsjava does not do this.
This means that if a user inserts values into /etc/hosts, they will be ignored by
the Address.getAllByName().
As a result, users who had expected stroke to honour values in /etc/hosts
(which is something you might want to do just for testing purposes) will be surprised
when it stops doing this.
So this patch reverts the code in question to use InetAddress instead of dnsjava's Address class.
Test Information
I added the following lines to my /etc/hosts file.
127.0.0.1 alexmac.com
127.0.0.1 alexmac.clayton.com
At time of the testing there already existed an external domain with name alexmac.com
but none corresponding to alexmac.clayton.com.
I then ran the 'Check DNS for a domain...' dialog in the MLC Help Menu.
Before the patch this would give me the the details for the external domain
for 'alexmac.com' and say no DNS could be found for 'alexmac.clayton.com'.
After the patch the correct details (i.e 127.0.0.1) were returned for both domains.
Also, before the patch I could not connect to the local xmpp server 'alexmac.com'.
After the patch I connected correctly.
Change-Id: If7f15b8aa98313278a1892eb27a5f73aaea8802b
|
|
There are limitations when using JNDI for DNS lookups, including that
it does not properly handle the situation when resolv.conf contains
IPv6 addresses (Isode bug #44832) - see e.g.
http://java.net/jira/browse/JITSI-295
JNDI is also not readily available on Android, which makes it slightly
more awkward to use Stroke on that platform.
This patch changes the PlatformDomainName classes so that they use
classes from dnsjava rather than JNDI.
The patch also updates the build scripts so that dnsjava.jar is
fetched (if necessary) and included in the build.
Indentation in build.xml has been tidied up
Test-information:
Ran unit tests - ok
Ran MLC - works OK and no longer throws NumberFormatExceptions
when resolve.conf contains "nameserver 2001:470:f052::2"
Change-Id: Iacf1105c52c281f9e59b60ea6caa011914b588dc
|
|
This patch should provide more information when Stroke receives invalid xml
or if an exception occurs.
Test-information:
deliberately caused an IllegalArg exception from an xmpp client and verified
that I received the exception message in logs and the xml
Change-Id: Id86b530f73f22c85ca36e54042ff7af74d55437d
|
|
Some discussion followed the "Fix synchronization problem in
ByteArray" patch, and that led us to believe that it would be better
to change the JavaConnection class so that it does not rely on being
able to pass ByteArrays around in a way that makes them vulnerable to
the problems that had been seen.
The JavaConnection class accepts a ByteArray in its "write()" method,
and emits a ByteArray when it has read data.
ByteArrays are not the ideal way for the JavaConnection class to
manipulate data and so this patch changes the implementation so that:
a) the "write()" method extracts the byte[] from the supplied
ByteArray and uses these objects, rather than keeping
references to the ByteArray objects (which might lead to
synchronisation issues).
b) the "doRead()" method uses a ByteArrayOutputStream to hold incoming
data, and only constructs a ByteArray out of it when it is ready to
return the data to the application.
These changes make the class more efficient, since in the case of (a),
the need to create temporary ByteArrays is removed, and in (b) the
code no longer creates ByteArrays by iterating through the network
data one byte at a time and appending it to a ByteArray.
It also means that the "synchronized" patch (which would fix the
problem) is no longer necessary, and so that code is reverted.
Test-information:
I patched the code to emulate the situation that would occur when a
buffer is only partially written, and verified that in this case it
correctly re-inserted the unwritten portion of the buffer at the
front of the pending queue.
Ran MLC to various servers, all seems to work OK.
Tested in Harrier, seems to work OK, and does not exhibit problems
that we had seen previously which led us to investigate this issue.
Change-Id: Ifcda547402430c87da45ba7d692518b5af285763
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
We noticed that in certain circumstances a stream of data being sent
to a server was being corrupted.
According to the "onDataWritten" signal, we could see that the data
which Stroke thought it was writing was valid, but by adding debug
code to the JavaConnection class, we could see that what was actually
being sent over the socket was wrong. For example, where
"onDataWritten" would report something like
some text for the server
the actual data being written to the socket (as shown by
toString() of the bytestream) would be something like:
some text fo\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300\200\300
i.e. the length of data is correct, but the last part of the buffer is broken.
We saw this on non-TLS connections, but never on TLS connections.
The reason for this (verified after some debugging) is that the
"ByteData.getData()" method was unsynchronized. In the failing cases,
two threads are calling this method at once. The first one finds that
"dataCopy_" is null, and so new's it and starts filling it with data.
The second thread calls "getData()" before this completes, which means
it sees "dataCopy_" as non-null, and uses that value (even though the
first thread hasn't finished populating it yet).
In the failing scenario, the two threads involved were (1) thread that
was handling the "onDataWritten()" callback (which called "getData()"
to get a String that it sent to a debug stream) and (2) the
JavaConnection code (which wants to write the data to the socket).
It seems likely that the reason this doesn't happen for TLS
connections is that in that case, the JavaConnection object will be
processing a ByteArray object that has been generated via the
SSLEngine (rather than the one which "onDataWritten()" sees, and so
the chance of two threads both calling "getData()" is reduced.
(I have not followed the TLS code path thoroughly to verify this).
So this change makes any method in ByteArray that touches "dataCopy_"
be synchronized (as well as hashCode() as suggested by findbugs)
Test-information:
Having inserted some debug code, I could reproduce the "data
corruption" problem reliably.
After adding the "synchronized" directive to "getData()", I could no
longer reproduce the corruption.
Ran MLC with this patch and works with no problems
Change-Id: I02008736a2a8bd44f3702c4526fd67369a3c136a
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
If a TLS connection results in the server choosing an anonymous cipher
suite, then no server certificate will be returned by the server.
This ought not to happen, since XMPP clients are expected only to
propose non-anonymous cipher suites, but it could be that a client is
coded to propose anonymous suites, or that a bug in the server means
that it fails to return a server certificate.
This change updates the ServerIdentityVerifier to make it resilient
against these situations, treating this situation as equivalent to
"certificate presented by server does not verify".
Test-information:
In my testing, I was deliberately using anonymous ciphers and getting
Stroke crashes. After this patch, I don't get Stroke crashes any more
(but the connection fails because the certificate verification fails).
Change-Id: Ia7b9b8dad7a054ff266a78ef33a56157320654c8
|
|
In the PlatformDomainNameResolver class there is a DomainNameAddressQuery
class (accesible via DomainNameResolver->createAddressQuery()) for
performing a DNS lookup on a given domainname. This should have been
returing the set of all HostAddress associated with a given domain, but
instead was only returning a singleton set (or empty if there was no dns).
This patch fixes this by changing the method call from
InetAddress.getByName() to InetAddress.getAllByName().
Test-information:
Tested on top of my MLC Diagnose SRV patch. For 'google.com' we now see a
full list of ip addresses associated with it, rather then just the one.
Change-Id: I6e57c16bb64f76048f16bcff8ee9c1924049a051
|
|
This change moves responsibility for creating the TLSContextFactory
from CoreClient into NetworkFactories, which is in line with the
Swiften implementation.
This means that a caller may now provide his own concrete
TLSContextFactory using code of the form:
NetworkFactories myNetworkFactories;
.
.
myNetworkFactories = new JavaNetworkFactories(eventLoop()) {
@Override
public TLSContextFactory getTLSContextFactory() {
return new MyTLSContextFactory();
}
};
Test-information:
I implemented separate TLSContextFactory and TLSContext classes that
used OpenSSL via JNI) to provide SSL functionality. I was able to
switch to using these with the mechanism that this patch provides.
I also verified that existing code which doesn't try to provide its
own NetworkFactories subclass still works as before (i.e. this patch
doesn't break existing applications).
Change-Id: Ibf07ddbbb4a4d39e4bb30a28be9aa0c43afe005f
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
It was noticed that in certain cases, Stroke got stuck when connecting
to a server over TLS, and the server closed down the connection.
Investigation showed that this appears to be caused by the JSSEContext
code not properly coping with a "close notify" SSL message. What
happens in this case is that the SSLEngine generates a response to the
server's "close notify", and expects this to be sent back over the
network.
The original JSSEContext code saw the "CLOSED" status from the
SSLEngine.unwrap(), but assumed that no more data would be generated
by the engine (which was wrong, because the engine wants to send a close
response back), and so got stuck in a loop.
This patch therefore fixes the JSSEContext code to deal properly when
it sees a CLOSED from unwrap.
After the close has been received, an error will be emitted by
JSSEContext so that the application knows that the SSLEngine can no
longer be used (in practice we have always seen the socket closing,
which generates its own error to the application, but it was
recommended that we should have this check in case a server sends a
close notify and does NOT close the socket as well).
It appears that many servers don't actually send the "close notify",
and just drop the connection, which is (presumably) why we'd not seen
this behaviour before.
Test-information:
Tested by connecting to the aforementioned server. This time, when
the connection times out (and the closenotify is sent), we no longer
see a loop, but the application realises what's happens and attempts
to reconnect.
I have been running with this patch in my copy of MLC for two weeks
and have noticed no difference in behaviour - so far as I can tell the
code is not exercised when talking to M-Link but at any rate the patch
isn't causing anything to break.
Change-Id: Id007c923c510ef1b4ce53192105b00296c65c757
|
|
It is possible to have a null selector if socketchannel open failed so adding a
null check in this patch.
Test-information:
sanity tested on linux by connecting/reconnecting on an xmpp service on linux
Change-Id: Idee180ca4aefd1f743705da674b486dd8acc4922
Reviewer: Nick Hudson <nick.hudson@isode.com>
Reviewer: Kevin Smith <kevin.smith@isode.com>
|
Swift