summaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)Author
2012-06-01Don't send non-integer 'h' attributes on 'a' elementsKevin Smith
2012-05-29Don't throw exceptions for receiving illegal XMLKevin Smith
2012-05-21Use the Aalto XML parser instead of XPPKevin Smith
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.
2012-04-27MUC Administration related classesGurmeen Bindra
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
2012-04-27Port Classes for Storage/Private StorageGurmeen Bindra
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
2012-04-27Remove "max" limit on buffer size for SSL connectionsNick Hudson
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.
2012-04-23Basic exampleKevin Smith
2012-04-20Also emit onDisconnected after a manual disconnectKevin Smith
2012-04-19Update parsing factories to allow empty namespaces, in line with SwiftenKevin Smith
2012-04-19Port MUC Payload Parsers from Swiften to StrokeGurmeen Bindra
This patch ports the MUC Payload parsers from swiften to stroke. Test-information: ported junits work fine
2012-04-19Port MUC Payload Serializers from Swiften to StrokeGurmeen Bindra
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.
2012-04-19Port elements for MUC AdministrationGurmeen Bindra
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.
2012-04-19Port Presence Sender from Swiften to StrokeGurmeen Bindra
The porting includes Directed and Stanza Channel Presence senders. Test-information: tested with Work In Progress MUC Admin Port's Unit tests
2012-04-19Add Signal and Slot classes with 3 parametersGurmeen Bindra
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
2012-04-19Add a copy constructor to Presence and Stanza + compare method in JIDGurmeen Bindra
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>
2012-04-19Port Error parser Tests to stroke from SwiftenGurmeen Bindra
Junit tests ported from Swiften to stroke. Test-information: ran the tests from Eclipse IDE
2012-03-29Make CoreClient.getSessionCertificate more robustNick Hudson
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.
2012-03-29Port Error Parser to strokeGurmeen Bindra
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>
2012-03-19Add "isTLSEncrypted" and "getPeerCertificate" to CoreClientNick Hudson
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
2012-03-19Update CoreClient to be a bit more in line with SwiftenNick Hudson
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.
2012-03-19Fix yet more of Remko's curly bitsKevin Smith
2012-03-13Fix up mistakes in previous patchNick Hudson
I broke the "getLocalAddress()" method. This fixes it. Test-information: By debugging and looking at "JavaConnection.toString()" output
2012-03-13Update JavaConnection to use SocketChannel rather than SocketNick Hudson
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.
2012-03-08Implement "CertificateWithKey" and add support for setting client certificatesNick Hudson
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
2012-03-07Stringprep JIDs through icu4jKevin Smith
2012-03-07Using JZlib for compression, as features we need aren't in Java until 1.7Kevin Smith
2012-03-07Turn on TLS ability (and fix problems discovered while testing this)Nick Hudson
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
2012-02-23Fix Stroke to allow empty valuesMili Verma
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.
2012-02-23Allow non-standard ports on internal interface methodKevin Smith
2012-02-14Add parsing of XMPP and SRV subjectAltNames to JavaCertificateNick Hudson
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>
2012-02-13Tidying up based on feedback from patch for initial TLS implementationNick Hudson
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
2012-02-13Update ByteArray with "readFromFile" implementation and more javadocNick Hudson
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>
2012-02-13Initial implementation of TLS supportNick Hudson
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.
2012-01-24Fix XML serialisation.Kevin Smith
Also port the unit tests from Swiften.
2012-01-24Fix to make DiscoItems workMili Verma
This fixes crashes. Test-information: No more errors.
2012-01-24Fix for DiscoInfo errorMili Verma
Updated class qualifier so it can be found by factory. Test-information: No more errors.
2012-01-23Update constructors of Command in line with swiftenMili Verma
Also fixes the call in OutgoingAdHocCommandSession which was sending null data and resulting in a crash when used in MLC. Test-information: No longer crashed MLC.
2012-01-19Some more "toString()" to help with development/debuggingNick Hudson
Also fixed up some incorrect Remko copyrights
2012-01-18Add toString to some more classesNick Hudson
Also made "Stanza" be an abstract class and had its ".toString()" include the name of the subclass which is involved, so that the subclasses don't have to do that themselves. Also added null check to existing HostAddress.toString() method Also fixed Remko copyright in Connector class Test-information: Stuff is displayed as expected in debugger.
2012-01-16Add support for DiscoItems and DiscoInfo.Kevin Smith
Updates requisite classes in line with Swiften. Also fixes bugs in the EventLoops not using handleEvent.
2012-01-16Update JavaTimer class to guard against premature timer expirationNick Hudson
The JavaTimer class uses Thead.sleep() to wait a specified number of milliseconds. Thread.sleep() requires the caller catch InterruptedException, but in the original implementation, such an exception would result in the code assuming that the specified time had been reached. So as things stood, if you e.g. set a timer for 60 seconds, then the timer might generate its "onTick" signal before that 60 seconds had elapsed. This patch changes the code so that the method will wait until the specified time has been reached. The "milliseconds" parameters are also changed to "long", which is the type used by the rest of the java library for millisecond values. Added a bit of javadoc and a toString() method as well. Note there is still a "FIXME" in the code which I've not addressed. Test-information: Tested in debugging setup; things seem to be working as expected.
2012-01-16Add "toString()" to a couple of classesNick Hudson
Just to help with debugging Test-information: Values appear as expected when running inside Eclipse debugger
2012-01-12Add some javadoc to Event.javaNick Hudson
In trying to use the Event class I wasn't sure exactly what it was doing so have added javadoc to try and make it clearer. I also added "toString()" method to Event.java for debugging purposes. Test-information: "ant javadoc" works and info looks as expected. Running in debugger now shows me info derived from "toString()" method when I click on Event objects
2012-01-12Add Javadoc for CoreClient, EventLoop, JIDMili Verma
Test-information: Looks okay.
2012-01-11Update review comment related stuffMili Verma
This patch addresses some review comments: 1. Updates the Javadoc. 2. Disallows arguments from being null - throws NullPointerException. 3. Updates each test to use its own DummyEventLoop. Test-information: Unit tests pass.
2012-01-09Fix misport of AttributeMap.getValue, which allowed it to return nullKevin Smith
2012-01-09Port Adhoc commands to StrokeMili Verma
This patch ports the Adhoc commands from Swiften to Stroke. It also ports their unit tests. Test-information: Unit tests pass. MLC able to use the ad-hoc command fine.
2011-11-03public oversightKevin Smith
2011-10-31Fix utf-8 encoding on Remko's name throughout. Now compiles with Java 7Kevin Smith
2011-07-18Remove obsolete warningKevin Smith