Sunday, September 27, 2015

STMP port 587 blocked by Windows firewall

Recently, I had problems trying to send emails using JavaMail and my Google gmail account. I read in many places that it was most likely my ISP provider, who was blocking my access to the service; however, I didn't believe it because I could send with the same java test program from a different computer within my network, an Apple with OSX, emails. The java test program I used for testing is given below and comes from the tutorialspoint website.

To see in my firewall protocol that the requests were being dropped, I had to first turn my firewall logging on which I did by opening up a command prompt with admin rights and executing the followng:

C:\>netsh advfirewall set allprofiles logging droppedconnections enable
Ok.

Then, I sent a request with the test program and saw in the logfile (%systemroot%\system32\LogFiles\Firewall\pfirewall.log) :

2015-09-27 09:28:37 DROP UDP 192.168.178.58 239.255.255.250 52323 1900 371 - - - - - - - RECEIVE
2015-09-27 09:28:37 DROP UDP 192.168.178.58 239.255.255.250 52323 1900 357 - - - - - - - RECEIVE
2015-09-27 09:34:12 DROP TCP 192.168.178.64 66.102.1.108 58144 587 0 - 0 0 0 - - - SEND

The test program threw the following exception:

>java -classpath .;mail.jar;activation.jar SendEmailUsingGMailSMTP
Exception in thread "main" java.lang.RuntimeException: javax.mail.MessagingException: Could not connect to SMTP host: smtp.gmail.com,
 port: 587;
  nested exception is:
        java.net.SocketException: Permission denied: connect
        at rewards.messaging.client.SendEmailUsingGMailSMTP.main(SendEmailUsingGMailSMTP.java:64)
Caused by: javax.mail.MessagingException: Could not connect to SMTP host: smtp.gmail.com, port: 587;
  nested exception is:
        java.net.SocketException: Permission denied: connect
        at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1972)
..
        at javax.mail.Transport.send(Transport.java:124)
Caused by: java.net.SocketException: Permission denied: connect

I should mention that with wireshark one will not see the requests because the requests don't make it beyond the firewall; however, if one clears the local DNS cache (C:\>ipconfig /flushdns), one can see with wireshark the hostname resolution request. This is nice because one can confirm that the destination address seen in the dropped TCP request is indeed the one associated with the program; the port number is also a good indication that one is looking at the correct request.  


Another useful tool was openssh, which I have installed on my Windows laptop because I'm using Git Bash. With openssl, I could get Google's x509 certificate using the following:

$openssl s_client -connect  smtp.gmail.com:465 -state -tls1

However, what didn't work was this:

$openssl s_client -connect  smtp.gmail.com:587 -state -tls1
Loading 'screen' into random state - done
connect: Bad file descriptor
connect:errno=10013

The dropped request was also logged accordingly in the firewall's protocol similarly to that shown above.

To trouble shoot, I took the following standard snippet of code taken from here:

import javax.mail.Message;
import javax.mail.MessagingException;
import javax.mail.PasswordAuthentication;
import javax.mail.Session;
import javax.mail.Transport;
import javax.mail.internet.InternetAddress;
import javax.mail.internet.MimeMessage;

public class SendEmailUsingGMailSMTP {
   public static void main(String[] args) {
      // Recipient's email ID needs to be mentioned.
      String to = "xyz@gmail.com";//change accordingly

      // Sender's email ID needs to be mentioned
      String from = "abc@gmail.com";//change accordingly
      final String username = "abc";//change accordingly
      final String password = "*****";//change accordingly

      // Assuming you are sending email through relay.jangosmtp.net
      String host = "smtp.gmail.com";

      Properties props = new Properties();
      props.put("mail.smtp.auth", "true");
      props.put("mail.smtp.starttls.enable", "true");
      props.put("mail.smtp.host", host);
      props.put("mail.smtp.port", "587");

      // Get the Session object.
      Session session = Session.getInstance(props,
      new javax.mail.Authenticator() {
         protected PasswordAuthentication getPasswordAuthentication() {
            return new PasswordAuthentication(username, password);
         }
      });

      try {
         // Create a default MimeMessage object.
         Message message = new MimeMessage(session);

         // Set From: header field of the header.
         message.setFrom(new InternetAddress(from));

         // Set To: header field of the header.
         message.setRecipients(Message.RecipientType.TO,
         InternetAddress.parse(to));

         // Set Subject: header field
         message.setSubject("Testing Subject");

         // Now set the actual message
         message.setText("Hello, this is sample for to check send "
            + "email using JavaMailAPI ");

         // Send message
         Transport.send(message);

         System.out.println("Sent message successfully....");

      } catch (MessagingException e) {
            throw new RuntimeException(e);
      }
   }
}



Friday, September 18, 2015

weak ephemeral Diffie-Hellman tomcat6


After upgrading from SUSE 10 to SUSE 11, which encompassed an OpenSSL library upgrade, some HTTPS clients like chrome (Version 45.0.2454.85) or  wget started getting the following error "Server has a weak ephemeral Diffie-Hellman public".  No server changes on the server side, namely tomcat6, had been made.





Attempts to solve the problem by changing the sslEnabledProtocols or sslProtocol attributes of the Connector element in the server.xml shown below were unsuccessful. Also desperate actions such as updating the US_export_policy.jar and local_policy.jar did not help either.

The final solution was to limit the cipher suits by adding the ciphers attribute to the SSL enabled connector. See below

<!-- Define a SSL Coyote HTTP/1.1 Connector on port 443 -->
 <Connector port="443"  SSLEnabled="true"
            protocol="org.apache.coyote.http11.Http11Protocol"
             scheme="https" secure="true"
            clientAuth="want" sslProtocol="TLS"
     ciphers="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA"

            keystoreFile="${catalina.base}/conf/%KEYSTORE%"
            keystoreType="JKS" keystorePass="%KEYSTOREPASS%"
            truststoreFile="${catalina.base}/conf/%TRUSTSTORE%"
            truststoreType="JKS" truststorePass="%KEYSTOREPASS%"

   />


Apache Tomcat's ciphers come from the under lying JVM, in particular the JSSE. To see which one are available put the following in a java main routine and run it.

/*******************************************/
StringBuilder sb = new StringBuilder();
try {
SSLParameters ssl  = SSLContext.getDefault().getSupportedSSLParameters();

sb.append("CipherSuites:\n");
for(String cs : ssl.getCipherSuites()){
sb.append(cs);
sb.append('\n');
}

sb.append("\nProtocols:\n");
for(String p : ssl.getProtocols()){
sb.append(p);
sb.append('\n');
}

} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}

return sb.toString();

/*******************************************/

The output should look something like this:

CipherSuites:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_KRB5_WITH_RC4_128_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5


Protocols:
SSLv2Hello
SSLv3
TLSv1




Tuesday, August 4, 2015

Download WSDL and include/imported XSD files

To reduce the external build dependencies of my maven web application project, in particular the jaxws-maven-plugin part of my project,  I stored the WSDL file and all its dependencies in my project and configured the plugin wsdlUrls to point to them. As shown below:

<configuration>
   <wsdlUrls>
         <wsdlUrl>${basedir}/src/main/resources/wsdl/SDMXQuery/SDMXQuery_1.wsdl</wsdlUrl>
   </wsdlUrls>
</configuration>

I downloaded all the files with SoapUI (Version 5.0.0) by creating a new SoapUI project with the URL of the WSDL as follows:


Then I clicked on the WSDL in the newly created project (See arrow 1 below), changed to the "WSDL Content" tab, and then pressed the small button (See arrow 2 below) with the tool tip: "Export the entire WSDL and include/imported files to a local directory". 


Then I chose the directory within my project.


After that, everything was nicely stored in the directory and could be configured in the POM file of my project as shown above.


Tuesday, July 28, 2015

jdbc driver with oracle wallets

The processes of converting a jdbc connection as configured in most java application can be confusing. These notes should provide some help and perhaps a better overview.

The first task is to create a wallet. Below, I created two sets of credentials for the same user; RIAD_JAVA. I created two because I wanted to try two types of configurations. One which uses the database connection string and the other which uses a TNS alias.

#first create the wallet 
mkstore -wrl t-riad-wallet -create

#create first of two credentials for user RIAD_JAVA. This will be used for configuration, which needs a tnsname.ora file.
mkstore -wrl t-riad-wallet -createCredential triad RIAD_JAVA secret2015$

#create second set of credentials also for RIAD_JAVA but this time with part of the connection string taken for the java programms externalized properties file. The configuration won't need a tnsname.ora file.
mkstore -wrl t-riad-wallet -createCredential t-riad-dwh-db.tadnet.net:1521/triad.tst.tadnet.net         RIAD_JAVA secret2015$

Before continuing, let me give an over view of what will be shown. 

1. Configuration Using thin client (jdbc:oracle:thin:)

   a.) with Database Configuration String (@hostname:port:service)
   b.) with TNS alias (@anyalias which can be found in tnsname.ora)

2. Configuration Using oci (jdbc:oracle:oci:)



1. Configuration Using thin client (jdbc:oracle:thin:) 


The following jars are needed:
ojdbc6-11.3.0.jar, oraclepki.jar and ucp.jar

a.) with Database Configuration String


Set up the Java application with the following connection string. This should correspond to what was used while creating the second set of credentials above.

jdbc:oracle:thin:/@t-riad-dwh-db.tadnet.net:1521/triad.tst.tadnet.net

Program must be started with the following JVM parameter:

oracle.net.wallet_location


Example:
java -cp .:/global/riad-app/tomcat/lib/ojdbc6-11.3.0.jar:./jlib/oraclepki.jar:./ucp.jar 
-Doracle.net.wallet_location=/tmp/wallet/t-riad-wallet  WalletTest


Note: no tnsname.ora file is needed only the a copy of the wallet created above.


b.) with TNS alias

The above mentioned jar will also be need here. This time the connection string is as follows, which is what was used to create the first set of credentials above.

jdbc:oracle:thin:/@triad

Program must be started with the following JVM parameters:

oracle.net.wallet_location
oracle.net.tns_admin

The following tnsnames.ora will be needed and should exist where oracle.net.wallet_location shown above points to.


 triad =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(Host = t-riad-dwh-db.tadnet.net)(Port = 1521))
    )
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = triad.tst.tadnet.net)
    )
  )

Example call:

java -cp .:./ojdbc6-11.3.0.jar:./jlib/oraclepki.jar:./ucp.jar -Doracle.net.wallet_location=/tmp/wallet/t-riad-wallet  -Doracle.net.tns_admin=/tmp/wallet WalletTest



2. Configuration Using oci (jdbc:oracle:oci:)

Here the jdbc connection string looks as follows:

jdbc:oracle:oci:/@triad


Before starting the programm the following enviroment variables are needed:

ORACLE_HOME=/opt/oracle/product/11.2.0;export ORACLE_HOME

LD_LIBRARY_PATH=/opt/oracle/product/11.2.0/lib:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH

Also a tnsname.ora file


and a sqlnet.ora file are need.









Friday, July 24, 2015

Unified Functional Testing from Hewlett Packard behind a NTLM proxy server.

A colleague of mine wanted to work with Hewlett Packard's UFT/QTP version 11 behind a proxy server, which only supported NTLM. The secret to making it work, because UTF version 11 doesn't support NTLM, was to install cntlm (version 0.92.3) from sourceforge between the test suite and the proxy server on the machine, which was hosting the HP program. After setting up the default cntlm.ini file with the proper proxy server host and port information, user name and password, cntlm was then started as follows:

cntlm -c cntlm.ini -u myuser@mydomain

When UTF asked for the proxy information, localhost and 3128, the port which cntlm was configure to listen on, were entered in the screen below:



Sunday, July 5, 2015

Creating a maven plugin with java 5 annotations rather than javadoc tags

Actually, creating a plugin with the Maven Plugin Tools, is something, thanks to the plugins themselves, which is relatively trivial; however, because it took me a long time to get my plugin working properly with Java 5 annotations rather than Javadoc Tags, I decided to write it down.

I must confess that, sadly enough, Maven has never been a strength of mine so that it was no surprise that my plugin didn't immediately function properly. The problem I faced was in the passing of the parameters to my Mojo during execution of my newly created plugin.

When converted to Java 5 annotation, the class "outputDirectory" attribute, in the default created Mojo,  was always null even though I had the proper configuration in my host project's pom.xml

<configuration>                     
    <outputDirectory>C:\Users\wnpr\Downloads</outputDirectory>         
 </configuration> 

To make sure that we all have the same starting point let me begin, by showing how I used the Maven Integration for Eclipse plugin, M2E, to create a new Maven project as shown below.


Then I selected the "maven-archetype-mojo" as a  temple for my new project,


  and finally gave my plugin a groupId and artefactId.


What follows is a view of the Maven project from within eclipse. As you can see, the project already contains a Mojo class, called MyMojo, which was created from me


Every plugin needs a plugin.xml file, which is generated by the maven-plugin-plugin and which can be found the the META-INF\maven folder of the generated jar file. By default, maven-plugin-plugin generates the plugin.xml file from the Mojo Javadoc Tags found in the Java code. These tags look like this:

/** 
 * Goal which touches a timestamp file. * 
 * @goal touch 
 * 
 * @phase process-sources 
 */

If you, as I did, would rather use Java 5 annotations, such as:

@Mojo( name = "touch" )
public class MyMojo
    extends AbstractMojo {

   @Parameter(defaultValue = "c:\\", required=true)
    public File outputDirectory;

   @Parameter(defaultValue = "Hello World!!!!", required=true)
    public String greeting;
.
.
}

for you plugin.xml generation, then you will have to rely on another plugin; namely: maven-plugin-annotations.

To do this you will have to add an additional dependency, to your plugin project's pom.xml.

<!-- dependencies to annotations -->
<dependency>
   <groupId>org.apache.maven.plugin-tools</groupId>
   <artifactId>maven-plugin-annotations</artifactId>
   <version>3.4</version>
    <scope>provided</scope>
</dependency>    


and override Maven core's default-descriptor execution phase to process-classes as follows:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-plugin-plugin</artifactId>
        <version>3.4</version>
        <executions>
          <execution>
            <id>default-descriptor</id>
            <phase>process-classes</phase>
          </execution>
          <!-- if you want to generate help goal -->
          <!-- 
          <execution>
            <id>help-goal</id>
            <goals>
              <goal>helpmojo</goal>
            </goals>
          </execution>
           -->
        </executions>
      </plugin>
      </plugins>
    </build>

It wasn't until this last change that the @Parameter annotated attributes of my Mojo were finally set properly during execution of my plugin.  Both of these additions are well described here; however, when I read them for the first time, I wasn't smart enough to understand them; as often is the case, and needed to waste a day before I finally came to my senses.

If you get a message like this:

Error extracting plugin descriptor: 'Goal: touch already exists in the plugin descriptor for prefix: junk
[ERROR] Existing implementation is: org.wmmnpr.junk_maven_plugin.MyMojo

then be sure to delete the old Javadoc Tags.

Good luck!

Thursday, February 26, 2015

Converting Spring boot standalone application to a web application

In the "Producing a SOAP web service" chapter of the "Getting Started" Guide from Spring, one creates a web service, which eventually runs as a standalone application. In the section Make the application executable, one reads:

"Although it is possible to package this service as a traditional WAR file for deployment to an external application server, the simpler approach demonstrated below creates a standalone application."

This blog is about the necessary changes actually needed to make the referred to web service available in a application server.

A good starting point, is to use maven archetype for a web application. This will provide the necessary structure needed for a web  application i.e. WEB-INF folder.

First add a ContextLoaderListener to your web.xml in the WEB-INF folder in order to instantiated a Spring container which will be shared by all Servlets and Filters. Because it was desirable to use an annotation style of configurations, an AnnotationConfigurationWebApplicationContext was instantiated (see contextClass context-param below) instead of the default XmlWebApplicationContext.

<web-app ..>

 <context-param>
     <param-name>contextClass</param-name>
     <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext
  </param-value>
 </context-param>
 <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>hello</param-value>
 </context-param>
 <!-- Creates the Spring Container shared by all Servlets and Filters -->
 <listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener
 </listener-class>

 </listener>
   <!-- take especial notice of the name of this servlet -->
    <servlet>
        <servlet-name>webservice</servlet-name>
        <servlet-class>org.springframework.ws.transport.http.MessageDispatcherServlet</servlet-class>
     <init-param>
       <param-name>transformWsdlLocations</param-name>
       <param-value>true</param-value>
     </init-param> 
    </servlet>

    <servlet-mapping>
        <servlet-name>webservice</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>

</web-app>

For the webservice, a MessageDispatcherServlet was also configured in the web.xml file as shown above. Make sure that the "transformWsdlLocations" attribute of the web service Servlet is set to true during instantiation.

The MessageDispatcherServlet, because it has not been otherwise indicated in the web.xml file, expects a  configuration file called  "webservice-servlet.xml" (servlet-name plus "-servlet"), which should be located in the WEB-INF folder. The contents of the file are shown below.

<beans>
  <sws:annotation-driven/>

   <sws:dynamic-wsdl id="countries" portTypeName="CountriesPort"locationUri="/ws/countries">
       <sws:xsd location="/WEB-INF/classes/countries.xsd" />
   </sws:dynamic-wsdl>

</beans>

With those changes done, it's now time to change our focus to the WebServiceConfig.java class also described in the guide. Here, the method for the bean definition "messageDispatcherServlet" should commented out as it's no longer needed. Everything else can stay the same.

The last thing that is needed is to add the countries.xsd file, as created in the "Getting Started Guide", to the application as a resource so that it can be found by the "countriesSchema" bean, which is instantiated in the WebServiceConfig class.

Once these steps have been completed, it should possible to deploy the war to an application server like Tomcat or run it using the maven "tomcat6-maven-plugin" plugin.

The code is available here as a zip.

Good luck.