Pages

Friday, 27 June 2014

Secure Copy of Files over a non Standard Port

This is a continuation of my blog on Transfer Files Between two Systems Over User Defined Ports. Felt the need to use SSL for the transfer. This is the first step in securing the transfer. As long as we ensure that the certificate on the server is not available to others, our transmission is secure. Will provide the changes for securing the transmission with a password later in another blog.

Setup for execution is available here.

Git available with the source code here.

Step 1: Create the certificate and the Keystore
Key can be generated using keystore. Execute the below command. Script to execute this on windows is available here.


keytool -genkey -alias filecopy -keyalg RSA  -keystore filecopykeystore.jks -storepass password -keypass password -validity 1000 -keysize 1024
Step 2: Code On Server Side to Accept Encrypted Socket


SSLServerSocketFactory sslserversocketfactory = (SSLServerSocketFactory) SSLServerSocketFactory
     .getDefault();
Step 3: Code On Client to initiated an SSL Connection



SSLSocket socket = (SSLSocket) SSLSocketFactory.getDefault()
    .createSocket();
socket.setSoTimeout(timeout);
socket.connect(new InetSocketAddress(host, port));
try {
 socket.startHandshake();
 return socket;
} catch (SSLException s) {
 socket.close();
 logger.info("Error in SSL Socket. Hence loading the socket to keystore::");
}

This is all it takes to establish a secure tcp connection. Refer the getSocket method in FileCopySocketConnectionUtil to fetch the public certificate of terver and add into the clientKeystore for establishing the SSL.

Saturday, 7 June 2014

ISO8583 BitMap Explained To be Used with JPOS


The Bitmap in the message provides information on the presence of other fields in the message. While using jpos, one does not have to populate it, as this gets populated based on the fields added automatically.
Refer this wiki for more details.

The BitMap in the message can be represented either as a Binary BitMap (e.g IFB_BITMAP) or an Asci/Hex BitMap(e.g IFA_BITMAP). When the message is packed using a binary representation, the bitmap would occupy 16 bytes of the message, whereas in the ASCII representation it would occupy 32 charachters. It can be explained with the following Simple example. 

Assume a message containing the following fields 2,3,6,11,12, 17, 64, 101 (including 0 as this is usually sent in all messages)
There are 8 bitmaps available, each bitmap representing the 128 fields available(ie 0 to 127)
The first 64 fields are considered as the primary bitmap and the next 64 to be the secondary, representing fields from 64 to 127. In many a message where we do not have to send the fields above 64 we do not even have to form the secondary bitmap. 
8 * 16 = 128

So each byte in the bitmap can hold information of 8 fields. Lets arrive at the position for the fields selected.
The nearest multiple of 8 for 2 ,3, 6  is 8 and 8/8 = 1
The nearest multiple of 8 for 11 and 12 is 16 and 16/8 = 2
The nearest multiple of 8 for 17 is 24 and 24/8 = 3
The nearest multiple of 8 for 64 is 64 and 64/8 = 8
The nearest multiple of 8 for 101 is 104 and 104 = 13


The table below provides the Binary represenation of each byte for the above example. It can be noticed that there are a total of 128 0 and 1s which indicates the presence and absence of the field.

BitMap PositionBinary RepresentationHex Code
101(F2)1(F3)001(F6)0064
2001(F11)1(F12)000030
31(F17)000000080
40000000000
50000000000
60000000000
70000000000
800000001(F64)01
90000000000
100000000000
110000000000
120000000000
13000001(F101)0004
140000000000
150000000000
160000000000

To visualize the representation of the filds in the bitmap, lets consider the first 16 fields and represent the value of field as 0 (not present) and 1 (present). The first two row in the table illustrates the first two bytes of the bitmap and an indicator whether the field exists or not. A byte contains 8 bits, thus 8 fields can be represented in a byte using either 0 or 1.


While the binary representation can go in as byte, the ASCII/Hex packaging of the bitmap will result in this using up 32 characters instead of 16 bytes in the message.

Consider a message packed using the byte representation having the above mentioned fields (assume for simplicity that all other fields contain char and not bytes). The bitmap usually falls outside the printable ASCII representation, hence have provided the hexadecimal equivalent of the field only for the BitMaps.



64308000000000010000000004000000

In the event that the same message is unpacked using an IFA_BITMAP instead of IFB_BITMAP, the parser expects 32 chars instead of 64 and for example would take the chars, in message 5 and 6 and take the byte equivalent, thus resulting in a parsing fields that would be totally different than what was actually passed, resulting in a failure on unpacking the message using JPOS.

Hope this helps someone looking at it in some way. Will be writing further on what needs to be done and care to be taken for packing and unpacking the ISO message using jpos.

Thursday, 5 June 2014

Transfer Files Between two Systems Over User Defined Ports

This is a continuation of my post for sending multiple files over a socket connection. Spent some time over the same to explore the possibility of connecting two systems over a port of the users choice. The output code is a command line code, involving a Socket Server and Client which can reside on either system. It can both push a file as well as receive it.
The code sample is just an attempt to transfer the file/files over the network or within the system.

What is available:

  • Copy a File from source to destination.
  • Copy a Folder from source to destination (subfolders are ignored).
  • Copy a Folder from source to destination (recursive).
  • Parallel copy of files.
Note: The files can be copied from either systems, ie it can either send the files out or request the files from the other system, so a two way copy is possible.

What can be Improved:
  • Secure the Server socket to accept connection from predefined devices/ip address
  • Use a token to validate the request (either a certificate/encrypted token etc), thus allowing only those with actual credentials to transfer.
Source:

The source code is available here.

Jar:
Have prepared a Jar which can be used as is (compiled on jre 1.7) to copy the files.

Steps To Run:

  1. Copy the zip file on the source system as well as the destination system (one setup ie enough if file has to be transferred within the same machine).
  2. The folder contains three bat files:
    • filecopyserver.bat -- This can be run as is and will start a Listening socket on port 50000. This can be changed by adding the port as an argument in this file.
    • getfilesclient.bat -- This can be executed if the requirement is to pull the file from a source to a target, the source and the target would have to be updated in this file.
    • putfilesclient.bat -- This can be executed if the file is on the system initiating the transfer and has to be moved to the other system.


Client Mode Setting:
  1. The getfilesclient and putfilesclient accepts the following arguments:
    • Ip Address/hostname where the listening service is running.
    • Port on which the service is listening
    • Source Folder/File
    • Target Folder/File
    • Number of parallel threads
  2. In addition the following optional arguments are supported on the client side (it can be passed as -r -o or in a single argument -ro/-or)
    • -r -- For following the filetree and copy all files and folders recursively. If not provided, the copy will not be recursive
    • -o -- Overwrite even if the files are already present (a checksum is done using CRC32 to compare whether the files in source and target are same). Default behaviour is not to overwrite.
Server Mode Setting:
  1. The filecopyserver.bat accepts the port as an optional argument. Default port if not provided is 50000. The port defined here should be the same as the one used while running the client.

Sunday, 1 June 2014

Running a REST Client developed using JDeveloper as a standalone client

UseCase:
Suppose you have a working Jersey based RESTful client/proxy (java client) generated using JDeveloper, and, you want to use this proxy as a standalone code. This post describes how this usecase can be achieved.
JDeveloper version used : 12.1.2.0.0
Eclipse version : Kepler

Steps:
In JDeveloper
Add a main() method to your REST proxy code and run it. The log will show you some lines as below before displaying the response of your code.

D:\12.1.2\jdeveloper\mywork\RESTClientApp\.adf
D:\12.1.2\jdeveloper\mywork\RESTClientApp\Project1\classes
D:\12.1.2\oracle_common\modules\asm-3.1.jar
D:\12.1.2\oracle_common\modules\jersey-core-1.17.1.jar
D:\12.1.2\oracle_common\modules\jersey-server-1.17.1.jar
D:\12.1.2\oracle_common\modules\jersey-servlet-1.17.1.jar
D:\12.1.2\oracle_common\modules\jersey-json-1.17.1.jar
D:\12.1.2\oracle_common\modules\jersey-client-1.17.1.jar
 -Djavax.net.ssl.trustStore=......Dhttps.proxyHost=localhost -Dhttps.proxyPort=8099 project1.EmpRESTClient

Here, note down all the JARs that are listed out along with the location from where they are coming. You will use this location later to pick these JARs. You can then comment out the main method. Next, deploy the Client project as a JAR as shown.

                      


                      


In Eclipse
In Eclipse, create a new folder called 'lib' under a Java project. Copy the application JAR created by you earlier into this folder. Also, copy the JARs noted down on running the main method. and paste them in this 'lib' folder.
Refresh your app in Eclipse to see the newly added JARs. Now select all the JARs from withing the IDE and right click and select Build Path -> Add to Build Path.
Thats it! You should be able to consume the client coded in JDev easily.
If you miss out on some JAR, you will end up with ClassNotFoundExceptions.