Svetlin Nakov - Blog » 2009

By design when we open an SSL connection in Java (e.g. through java.net.URL.openConnection(”https://….”)) the JSSE implementation of the SSL protocol performs few validations to ensure the requested host is not fake. This involves validation of the server’s X.509 certificate with the PKIX algorithm and checking the host name agains the certificate subject.

Consider we are trying to download a resource from HTTPS server:

If the server uses self-signed X.509 certificate, we will get the following exception during the SSL handshaking:

This exception can be avoided if we import the server’s self-signed certificate in the JVM trusted store, a file called “cacerts”. For more information see this post: http://www.java-samples.com/showtutorial.php?tutorialid=210

We could have also another issue. If the server uses trusted certificate (issued from trusted CA like VeriSign), but for different host, we will get another exception during the host verification step of the SSL handshaking:

Avoiding these exceptions is possible by switching off the certificate validation and host verification for SSL for the current Java virtual machine. This can be done by replacing the default SSL trust manager and the default SSL hostname verifier:

import java.io.InputStreamReader;
import java.io.Reader;
import java.net.URL;
import java.net.URLConnection;

import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSession;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import java.security.cert.X509Certificate;

public class Example {
	public static void main(String[] args) throws Exception {
		// Create a trust manager that does not validate certificate chains
		TrustManager[] trustAllCerts = new TrustManager[] {new X509TrustManager() {
				public java.security.cert.X509Certificate[] getAcceptedIssuers() {
					return null;
				}
				public void checkClientTrusted(X509Certificate[] certs, String authType) {
				}
				public void checkServerTrusted(X509Certificate[] certs, String authType) {
				}
			}
		};

// Install the all-trusting trust manager
		SSLContext sc = SSLContext.getInstance("SSL");
		sc.init(null, trustAllCerts, new java.security.SecureRandom());
		HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
		
		// Create all-trusting host name verifier
		HostnameVerifier allHostsValid = new HostnameVerifier() {
			public boolean verify(String hostname, SSLSession session) {
				return true;
			}
		};
		
		// Install the all-trusting host verifier
		HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
		
		URL url = new URL("https://svn.academy.devbg.org:9024/");
		URLConnection con = url.openConnection();
		Reader reader = new InputStreamReader(con.getInputStream());
		while (true) {
			int ch = reader.read();
			if (ch==-1) {
				break;
			}
			System.out.print((char)ch);
		}		
	}
}

Voilla! Now the code runs as expected - it downloads the resource from an https address with invalid certificate.

Be careful when using this hack. Skipping certificate validation is dangerous and should be done in testing evironments only.

Posted by nakov as blog at 3:24 PM EEST

Comments Off

In a recent Java project I needed to develop and provide to external clients a RESTful Web Services interface to an internal system. After some research I found that using JAX-RS and its open-source implementation Jersey with Spring and Hibernate as back-end will be great technologies stack for this project. Seems easy but unfortunately I found that JAX-RS does not support optional path parameters.

Customer requested each service to have an optional path parameter called “format” that specifies the output format. All services were required to support multiple output formats: XML, plain text, CSV, JSON, PDF, etc. For example if I request this URL: http://myserver.com/services/location/3/format/xml, the output should be XML, but if I request just http://myserver.com/services/location/3 without “format” parameter, the result should be plain text.

Mandatory Path Parameters

Using a path pattern like this:

makes the parameter “format” mandatory. If we skip it, the request will not match the path.

Optional @Path Parameters in JAX-RS

Using regular expressions and a simple hack can overcome this limitation in JAX-RS. The following example defines two optional path parameters “format” and “encoding”:

Requesting http://localhost:8080/services/user/3, will return “No format specified. No encoding specified”.
Requesting http://localhost:8080/services/user/3/format/pdf/encoding/utf8, will return “Format=pdf Encoding=utf8″.
Requesting http://localhost:8080/services/user/3/encoding/utf8, will return “No format specified. Encoding=utf8″.

Flexible @Path Parameters in JAX-RS

If we need more flexibility, we can match the entire path ending in the REST request and map it in key-value style (HashMap< String, String >):

@GET
@Produces({"application/xml", "application/json", "plain/text"})
@Path("/location/{locationId}{path:.*}")
public Response getLocation(
  @PathParam("locationId") int locationId,
  @PathParam("path") String path) {
 Map< String, String> params = parsePath(path);
 String format = params.get("format");
 if ("xml".equals(format)) {
  String xml = "<location></location><id></id>" + locationId + "";
  return Response.status(200).type("application/xml").entity(xml).build();
 } else if ("json".equals(format)) {
  String json = "{ 'location' : { 'id' : '" + locationId + "' } }";
  return Response.status(200).type("application/json").entity(json).build();
 } else {
  String text = "Location: id=" + locationId;
  return Response.status(200).type("text/plain").entity(text).build();
 }
}

private Map< String, String > parsePath(String path) {
 if (path.startsWith("/")) {
  path = path.substring(1);
 }
 String[] pathParts = path.split("/");
 Map< String, String > pathMap = new HashMap< String, String >();
 for (int i=0; i < pathParts.length/2; i++) {
  String key = pathParts[2*i];
  String value = pathParts[2*i+1];
  pathMap.put(key, value);
 }
 return pathMap;
}

Requesting http://localhost:8080/services/location/3, will return “Location: id=3″.
Requesting http://localhost:8080/services/location/3/format/json, will return “{ ‘location’ : { ‘id’ : ‘3′ } }”.

Enjoy!

Posted by nakov as java, blog at 2:47 AM EEST

Comments Off

The .NET Framework does not provide standard functionality for resolving a path relative to the application root to a physical file system path. Thus in ASP.NET Web applications we need to use Server.MapPath(), but in console and Windows Forms applications we need to rely on the current directory. Moreover if we run a Web application in the “Visual Studio Development Web Server”, the current directory is the root of the Web application, but when we deploy the application in IIS we find that the current directory is different. .NET developers need functionality that resolves a relative path in “tilde” style to a physical path that works in both Web and desktop scenario. Thus they can always use relative paths like “~/config/users.xml” and don’t need to change anything when moving a code from a Web application to desktop application.

Below is the source code in C# of my universal file path resolver that many developers could find useful:

/// <summary>
/// Author: Svetlin Nakov
/// URL: http://www.nakov.com/blog/2009/07/14/universal-relative-to-physical-path-converter-for-windows-forms-and-aspnet/
/// </summary>
public class FilePathUtility
{
    /// <summary>  
    /// Resolves a relative path starting with tilde to a physical file system path. In Web application  
    /// scenario the "~" denotes the root of the Web application. In desktop application scenario (e.g.  
    /// Windows Forms) the "~" denotes the directory where the currently executing assembly is located  
    /// excluding "\bin\Debug" and "\bin\Release" folders (if present).  
    ///   
    /// For example: the path "~\config\example.txt" will be resolved to a physical path like  
    /// "C:\Projects\MyProject\config\example.txt".  
    ///   
    /// </summary>  
    /// <param name="relativePath">the relative path to the resource starting with "~"</param>  
    /// <returns>Full physical path to the specified resource.</returns>  
    public static string ResolvePath(string relativePath)
    {
        if (relativePath == null || !relativePath.StartsWith("~"))
        {
            throw new ArgumentException("The path '" + relativePath + "' should be relative path and should start with '~'");
        }

HttpContext httpContext = HttpContext.Current;
        if (httpContext != null)
        {
            // We are in a Web application --> use Server.MapPath to get the physical path  
            string fullPath = httpContext.Server.MapPath(relativePath);
            return fullPath;
        }
        else
        {
            // We are in a console / Windows desktop application -->  
            // use currently executing assembly directory to find the full path  
            Assembly assembly = Assembly.GetExecutingAssembly();
            string assemblyDir = assembly.CodeBase;
            assemblyDir = assemblyDir.Replace("file:///", "");
            assemblyDir = Path.GetDirectoryName(assemblyDir);

// Remove "bin\debug" and "bin\release" directories from the path  
            string applicationDir = RemoveStringAtEnd(@"\bin\debug", assemblyDir);
            applicationDir = RemoveStringAtEnd(@"\bin\release", applicationDir);

string fullPath = relativePath.Replace("~", applicationDir);
            return fullPath;
        }
    }

private static string RemoveStringAtEnd(string searchStr, string targetStr)
    {
        if (targetStr.ToLower().EndsWith(searchStr.ToLower()))
        {
            string resultStr = targetStr.Substring(0, targetStr.Length - searchStr.Length);
            return resultStr;
        }
        return targetStr;
    }
}

Note that this class removes automatically the “\Bin\Debug” directory suffix generated by Visual Studio during the compilation so you can rely that “~” denotes the root directory of the application not depending of the project type (Web / Console / Windows Forms / WPF / Class Library / Windows Service / etc.).

Note also that we should use Assemble.CodeBase instead of Assembly.Location because in certain circumstances these locations differs (e.g. if the application runs inside NUnit Runner). The above code of course would work under the assumption that the assembly is stored locally (comming from the file system, not from the network) [as of 13-Nov-2009].

Posted by nakov as .net, blog at 2:27 PM EEST

Comments Off

Most people believe that Web applications should use only standard fonts like “Arial” and “Courrier New”. I think so (at least for the moment) but sometimes Web designers use non-standard fonts and you find out about this few months later. What to do? How to make the application behave correctly?

Embed the Non-Standard Font into the CSS

Good idea, but this is only supported in some Web browsers. Internet Explorer can embed fonts in their “EOT” format, while Firefox 3.5 and Safari 4 can embed standard “TTF” fonts.

Converting a TTF font to EOT is another (and unpleasant) story, so let’s assume we have the EOT version of the required font. Now we need to create CSS which loads the EOT font in Internet Explorer and the TTF font in all other browsers. To ensure we support both IE and Firefox/Safari we can use multiple @font-face definitions. We should start from the IE definition first (EOT font) and after it put the Firefox definition (TTF font). Here is how it looks like (I experimented with Arial Narrow, Bold):

The result of this example is as follows:

It runs correctly in IE6, IE7, IE8, Firefox 3.5 and Safari 4 (Windows) and does not run correctly in Firefox 2, Firefox 3, Opera 9 and Chrome.

Download the entire source code here: Arial-Narrow-Bold-example.zip.

Posted by nakov as blog at 5:40 PM EEST

Comments Off

Svetlin Nakov - Blog

Thoughts on Software Engineering

My Projects

Useful Links

Disable Certificate Validation in Java SSL Connections

JAX-RS, @Path, @PathParam and Optional Parameters

Mandatory Path Parameters

Optional @Path Parameters in JAX-RS

Flexible @Path Parameters in JAX-RS

Universal Relative to Physical Path Converter for Windows Forms and ASP.NET

Embedding a Font into Web Application

Embed the Non-Standard Font into the CSS