| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: Iba3aeab8b0140c32f732ce01b1e2da243e7ec141
|
|
Change-Id: If5ef43f2d875f958cd8114b0b3246e6e6f03c95b
|
|
|
|
|
|
|
|
|
|
Makes ClientOptions do more.
|
|
|
|
|
|
|
|
The method was comparing the classes instead of instances as a result of which
equal JIDs but belonging to different derived class were always unequal.
Test-information:
Tested using an XMPP client which is using objects of class derived from JID
class to compare with raw JID objects
|
|
|
|
In order to make it available to clients.
Test-information:
tested using an XMPP Admin tool to display connection type error
|
|
In one of my testing scenario, socket was not getting closed. This was happening when
an XMPP client was connecting to a domain which was different from the domain in the
jabber ID of the connection user. Moving the close call to a finally block ensures that
socket gets closed in all scenarios.
Test-information:
I created an IM domain j.com on my XMPP Server and then added a user with that
domain (user@j.com). Then I tried connecting to my Primary domain using this
new user. After removing j.com, I could an increase in number of sockets after
every poll (coreclient.connect()) but not after this patch.
|
|
If I leave an Application using Stroke running for a few hours(making periodic
connection attempts), the JVM would throw an Exception saying "Too Many Open Files".
On doing an "lsof -p <pid_of_jvm>", I noticed that there were number of open
sockets in CLOSE_WAIT state and these went up after every attempt to do a
connect on CoreClient object.
Closing of DirContext object fixes this bug and the number of open sockets
does not increase.
Test-information:
Ran MLC and kept on monitoring the result of "lsof -p <pid>". It would not
increase after this patch.
|
|
|
|
|
|
|
|
Also adds a 'make test' target for the Makefile. Set the JUNIT environment variable to point to your jar if it doesn't find it.
|
|
This change ports the MUC Administration related classes from
Swiften to stroke. Also includes the MUC initialisation code in
the CoreClient.
Test-information:
tested the ported unit tests
|
|
This patch ports the classes for Storage, PrivateStorage and PrivateStorage
requests from Swiften to Stroke.
Test-information:
junit test for GetPrivateStorageRequestTest is also ported and tested
|
|
The original implementation of JSSEContext allocated buffers for the
SSL data which started off at a size determined using information from
the SSLSession, and which were allowed to grow to up to ten times
their original size.
When testing with jabber.org it was fairly easy to exceed this size
(e.g. requiring a buffer of ~650K where the maximum value had been
around 160K), meaning that applications would fail.
This change removes the upper limit altogether. Now, the buffer will
grow to whatever is required, so long as free memory is available.
I also renamed "enlargeBuffer" in response to a previous review comment
Test-information:
No longer see problems when talking to jabber.org over
SSL. Instrumentation shows that buffer is growing as expected.
|
|
|
|
|
|
|
|
This patch ports the MUC Payload parsers from swiften to stroke.
Test-information:
ported junits work fine
|
|
All the serializers for different kind of MUC payloads have
been ported from swiften to stroke.
Test-information:
There is a junit test that's ported which tests the admin payload serialiser.
Also executed the other MUC Junits.
|
|
This patch ports basic elements from swiftern to stroke.
This includes various types od MUC Payloads.
Test-information:
the junits for the parsers (still WIP) code works fine.
|
|
The porting includes Directed and Stanza Channel Presence senders.
Test-information:
tested with Work In Progress MUC Admin Port's Unit tests
|
|
MUC Admin requires Signals and Slots with 3 parameters so this patch adds
Signal/Slot classes which cater to 3 parameter values
Test-information:
tested with Work In Progress MUC Admin code
|
|
This patch adds a copy constructor to the Presence class(and hence base class
Staza as well). It also ports the compare method to JID class.
Also added javadocs to Presence and Stanza classes.
Test-information:
tested using the Work In Progress code that ports MUC Admin to stroke
Reviewer: Kevin Smith <kevin.smith@isode.com>
|
|
Junit tests ported from Swiften to stroke.
Test-information:
ran the tests from Eclipse IDE
|
|
The javadoc for the method was not in line with its behaviour, so you
could get a NullPointerException if you asked for a session
certificate when the session wasn't TLS.
This patch makes the code do what the javadoc says (and what clients
most likely want)
Test-information:
Returns null rather than crashing when I ask for a certificate on a
non-TLS stream.
|
|
After this change, the error payload object should be populated in case of error.
The condtion, type and text field will be from the payload rather than Undefined,
Cancel and empty.
Test-information:
tested by executing adhoc-commands on an XMPP clinet in a way to result
in an error. I do see the error text and condition set as per the XMPP streams.
Reviewer: Kevin Smith <kevin.smith@isode.com>
|
|
Corresponding with change in Swiften (assuming that is approved; it's
not yet been integrated at the time of writing)
Test-information:
Works as expected in my test applications
|
|
This change
- renames the "onError" signal to be "onDisconnected" (as per change
59be74ec6 in Swiften)
- adds "setCertificateTrustChecker()" method and uses the supplied checker
when configuring TLS
Test-information:
My applications still work.
When I configure my server with a certificate that doesn't correspond
to the requirements in RFC 6120, my CertificateTrustChecker gets
called, and the session is either dropped or maintained depending on
what my checker returns.
|
|
|
|
I broke the "getLocalAddress()" method. This fixes it.
Test-information:
By debugging and looking at "JavaConnection.toString()" output
|
|
The initial implementation of JavaConnection used the "Socket" class,
from which it derived InputStream and OutputStream objects to read/write data.
In order to avoid blocking, the "read" loop would only attempt to read
data if the InputStream.available() method indicated that there was
data ready to be read. However, in order to determine that an
InputStream has been closed, you have to read from it and have it
return -1 to indicate "end-of-stream".
There was no explicit test for a -1 return, but even if there had
been, it wouldn't have tripped, because of the "available()" test.
So this change makes JavaConnection use "SocketChannel" rather than
Socket, which allows (when you configure the SocketChannel to be
non-blocking) you to issue non-blocking reads which *can* return -1
when the input stream has finished.
Test-information:
Tested with test program and MLC, using both TLS and non-TLS
connections. Applications still work as expected.
Observed that when I deliberately stop the server, or break the socket
connection, the client almost immediately gets a "disconnected"
signal.
Prior to this change, stopping the server results in the client
getting a disconnected signal only when it next tries to write
something.
|
|
This change provides the functionality to allow clients to specify a
PKCS#12 file containing client certificate/key for use when starting
TLS sessions.
The PKCS12Certificate class now subclasses "CertificateWithKey"
(matching the Swiften implementation).
Swiften also has "CAPICertificate", which is another subclass of
CertificateWithKey. This has not been provided in this patch.
From a client's point of view, all that's necessary to specify a
certificate to be used for TLS is to do something like
CertificateWithKey myCert = new PKCS12Certificate(
"/home/fred/myp12file.p12",
"secret".toCharArray());
coreClient.setCertificate(myCert);
before calling "CoreClient.connect".
Matching the Swiften functionality, constructing a new
PKCS12Certificate does not actually perform validation of the P12
file/passphrase; that takes place when the p12 file is used.
There is limited scope for returning to the caller errors describing
possible problems, but JSSEContext uses the "emitError" method which
does maintain error information, which is available in a debugger, or
from the JSSEContext.toString() method.
Test-information:
Set up an M-Link server with TLS verified that
- when I specify a client certificate with suitable SAN, the client
sends it and the server reports authentication using the certificate
- when I specify a client certificate without a suitable SAN, the
client sends it but the server rejects it
|
|
|
|
|
|
The nascent support for TLS is now enabled by the uncommenting of a
line in "PlatformTLSFactories" which means that Stroke will now try
and negotiate TLS when connecting to a server that offers it.
Note that further changes will be required to allow configuring of
client certificate and trust anchors.
In performing testing, a couple of problems were found and have been
fixed by this patch:
- The "hack" field inside JSSEContext, which keeps track of whether
the fake "<" character used to provoke an SSL handshake has been
sent was mistakenly declared static, which meant that if you tried
using TLS on more than one session, things didn't work
properly. This has been fixed.
- The buffer used for incoming encrypted data for the SSLEngine in
JSSEContext is created with a size that matches "the largest
SSL/TLS packet that is expected". But it turns out not to be big
enough to cope with all the data that the JavaConnection class
might provide when calling "handleDataRead()".
So the "handleDataFromNetwork" method is changed to break this data
into chunks that will fit into the buffer. The same technique is
used in "handleDataFromApplication" for cases where the application
provides more data than is will fit in a buffer.
- All of the "ByteBuffer" values are initialised with a size as
recommended by the Sun documentation, although in some cases it
appears that these sizes may not be enough (you are cautioned to be
able to cope with the buffers overflowing)
So all of the ByteBuffers are able to grow, up to a maximum of ten times
there initial size, using the "enlargeBuffer()" method.
Note that in most cases, I could only provoke buffer overflows in
my tests by deliberately starting off with buffers that are too
small.
- When testing with JRE7, it became apparent that the behaviour of
the SSLEngine and SSLContext classes had changed, which initially
resulted in "hangs" being seen as the SSLEngine did not appear to
decrypt data being fed to it until subsequent SSL messages arrived
and appeared and to prod it into life.
This behaviour is influenced by the version of TLS handshake being
used, which made it awkward to debug, since some versions of TLS handshake
worked fine for JRE6 but not JRE7 and vice versa; also different servers
would negotiate different with different handshakes.
Eventually this turned out to be a pre-existing bug in the initial
JSSEContext implementation: specifically the "unwrapPendingData()"
method had been assuming that a call to SSLEngine.unwrap() would
consume all pending data (which is the case for in all scenarios
using JRE6, and is often, but not always, the case for JRE7).
So the fix for the problem is to loop inside "unwrapPendingData" until
calls to unwrap() don't consume any more data.
- I also added some logging to JSSEContext - warnings when an error
is emitted, and a "fine" message when buffer sizes have to be
increased.
- Also, double-slash comments are replaced by /*..*/ style in JSSEContext
Test-information:
Before this patch, TLS wasn't starting. Now it does.
Before the bug fixes, concurrent TLS connections to more than one
server resulted in "corruption" of the streams, with errors being
generated relating to XML parsing errors at both client/server.
Before the bug fixes, large messages from the server (~36K) would
cause "BufferOverflow" exceptions and connections to drop.
After the bug fixes, these problems are no longer seen.
Before the bug fixes, TLS sessions would sometimes (depending on what
version of TLS the server negotiated, and what version of JRE you were
using) appear to "hang". Now they don't.
I also tested creating artificially small buffers to make sure that
the various "buffer overflow" situations are handled properly. I
wasn't able to provoke all of these problems in a real
configuration, so I suspect that the "enlargeBuffer" stuff may not
actually get used much, but it has been tested.
All tested with JRE6 and JRE7
|
|
This patch gives a fix to a client of Stroke can send emtpty values in form
fields.
Test-information:
Tests pass.
Before patch, MLC is not able to send empty values in updates. After the patch,
it is.
|
|
|
|
The JavaCertificate class functionality copies that found in Swiften's
OpenSSLCertificate class. One of the things that the class needs to
do is make available lists of SRV and XMPP names which are contained
in the certificate's subjectAltName extensions.
However, unlike OpenSSL, the standard Java classes don't provide
support for parsing the different types of subjectAltNames that we
want - what Java provides is a method to return the DER encoded
values, and so this change adds functions to the JavaCertificate class
to parse these values to extract Strings corresponding to either
XMPP or SRV subjectAltNames.
Also addressed a couple of comments from a previous patch.
Test-information:
Tested with certificate that has subjectAltNames for
- Service Name _xmpp-client.funky.isode.net
- Service Name _xmpp-server.funky.isode.net
- XMPP address funky.isode.net
- DNS Name funky.isode.net
And verified that all of these are parsed and made available with the
relevant methods.
Verified that a certificate which does NOT contain any of these
subjectAltNames is parsed with no errors (and the code reports no
matching subjectAltNames)
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
Hopefully the changes speak for themselves.
Some feedback relating to JavaCertificate has not been addressed; that
will be done in a separate patch
Test-information:
Can still establish sessions with / without TLS
|
|
This change provides implementation for the previously empty
"readFromFile" method, which is based on the code inside Swiften's
ByteArray.readByteArrayFromFile().
Note that, as for the Swiften method, no errors are reported if an
attempt to read from a file fails; it just leaves the contents of the
object unchanged.
Some javadoc was also provided, especially noting that the various
String methods are only safe so long as you're working with UTF-8
Strings.
Test-information:
Existing Stroke unit tests still pass
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
Note that TLS won't be enabled with this patch unless you uncomment the
change in PlatformTLSFactories. With that comment removed, then a new
CoreClient session will attempt to negotiate TLS if the server supports
it.
Further changes are required to support this properly, as there
appears not to be comprehensive support in the CoreClient class for
dealing with situations when the server's certificate is not acceptable.
There's also no support yet for setting up client certificates.
Further changes will also be needed (see below) to support full
parsing of subjectAltNames from server certificates.
Significant changes are as follows
- TLSProceed - FIXME comments removed
- JavaConnection - changed so that it reads bytes from the socket's
InputStream, rather than reading chars and then constructing a
String out of them from which a byte array is then extracted.
While this seemed to work for non-binary data (e.g. non-encrypted
XMPP sessions), it breaks when you start sending binary (i.e. TLS)
data.
- JavaTLSConnectionFactory - implemented
- PlatformTLSFactories - By having this return a JSSEContextFactory, then
this will cause the client to try TLS if possible. But because other
changes are needed to make this work properly, the current code still
returns null.
- JSSEContext - new class which uses an SSLEngine to handle TLS handshake
and subsequent encryption/decryption. This is the main substance of
the SSL implementation
Note the "hack" in here to cope with SSLEngine requiring that some data
be sent from the application before it will do a TLS handshake
- JSSEContextFactory - just creates JSSEContexts
- JavaCertificate - this wraps an X509Certificate and does *some* of the
parsing of a certificate to look for stuff that is expected when
verifying an XMPP server certificate (RFC 6120 and RFC 6125). Note that
the JDK classes for parsing certificates don't provide an easy way
to decode "OTHER" subjectAltNames, and so this implementation does
not find XMPP or SRV subjectaltnames from the server certificate. This
will need extra work.
- JavaTrustManager - obtains the server certificate from the TLS handshake
and verifies it. Currently the only verification done is to check that
it's in date. More work will be needed to perform proper validation
- Where necessary, Remko's copyright comments were changed from GNU to
"All rights reserved". Isode copyright notices updated to "2012"
Test-information:
Set up XMPP server with its own certificate, and checked that TLS gets
negotiated and starts OK (provided the server cert contains e.g. a DNS
subjectAltName matching its own name). Subsequent operation appears
to be as expected.
|
|
Also port the unit tests from Swiften.
|
Swift