Salient Soft

I was getting fed up with the various hacks and switches needed e.g. in Chrome to persuade it to use an ordinary self signed certificate to allow ssl for localhost during local development and testing.

My holy grail was to have seamless self signed localhost certificate support, such that the browsers would not complain at all or need any special hacks, but ‘just work’, and without any nasty warnings in the address bar. I wanted to use the same certificate in a Java Keystore for Spring Boot, as well as with a node http-server for serving webpack bundles. After much fishing around, the following solution worked for me.

Summary of Issues found/solved

1/ You can get a self signed cert to be fully trusted locally if you add it to the local computer’s Trusted Root Certification Authorities Store. For windows this is straightforward with the management console – details below in the steps.

2/ In addition, the certificate needs to have a Subject Alternative Name (SAN) defined as localhost, or Chrome will spit it out with a Common Name error. This is a misnomer – the problem is not with the Common Name, it is due to the lack of a correct SAN. Just setting the Common Name (CN) to localhost is deprecated and will no longer work in Chrome.

3/ The Java Keytool can create a keystore containing a certificate with a SAN, using the ext switch. This is detailed here for Java 7 (see the table under the -ext switch). It also works for Java 8 but I found the above docs somewhat clearer than those for java 8. However, I could not find a way to add multiple SAN DNS references, e.g. for localhost and for www.localhost.

4/ I found a way via this post here to use openssl to create a certificate keystore containing the certificate, which I could then import into a java keystore using keytool. openssl  was able to create multiple SAN DNS entries as required. My previous post here links to this post re setting up a Wamp Server, which links to this page re installing openssl.

5/ A trivial gotcha which I hit initially – once you have created and installed the certificate e.g. in the computer’s trust store as above, make sure that this certificate is also the exact one that you are using with all your web servers – in this case, http-server and Spring Boot.

6/ Once all done and working, I could happily use Chrome, IE11 and Firefox without any hacks or switches for self signed certs, and without any hacky warning on the address bar – just the normal black padlock.

Steps to Implement the Solution.

1/ I created a config file for openssl, e.g. req.cnf, as follows:

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = GB
O = Salient Soft Ltd
CN = localhost
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = www.localhost

2/ I created the certificate and key via openssl using the above config file:

openssl req -x509 -nodes -days 36500 -newkey rsa:2048 -keyout ss-localhost-cert.key -out ss-localhost-cert.crt -config req.cnf -sha256

3/ Import the certificate and key into a PKCS12 store, and then import that store into a java keystore with keytool:

openssl pkcs12 -export -name salientsoftdev -in ss-localhost-cert.crt -inkey ss-localhost-cert.key -out ss-localhost-cert-keystore.p12
keytool -importkeystore -destkeystore salientsoft.p12 -storetype PKCS12 -srckeystore ss-localhost-cert-keystore.p12 -srcstoretype pkcs12 -alias salientsoftdev

4/ Use the Microsoft Management Console to import the above certificate (ss-localhost-cert.crt) into the local computer’s Trusted Root Certification Authorities Store. This post  details how to do this on Windows 10, but Windows 7 was the same.

5/ I used the final keystore for Spring Boot (per details here), and the certificate and key files for node http-server (per details here).

Comments Off on Creating a fully trusted Self Signed localhost certificate

I was using this to add CORS headers dynamically based on application.properties.

However initially Spring stubbornly refused to add the headers.

My initial (incorrect) code was as follows:-

@Configuration
@EnableWebMvc
public class WebConfig implements WebMvcConfigurer {
 
    @Autowired
    private ConfigProperties config;
   
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        config.getCorsOriginsAllowed().forEach(origin -> registry.addMapping(origin).allowedOrigins(origin));
    }
}

The error was that I had used origin both as the registry mapping key and the resulting allowed origin.

The correct code should have used a URL path as the mapping key. The correct replacement line was as follows:-

        config.getCorsOriginsAllowed().forEach(origin -> registry.addMapping("/**").allowedOrigins(origin));

This fixed version mapped every URL path to the given set of origins, using “/**” as above.

This fixed the problem.

This post here by Baeldung and this Spring guide post detail the various ways to add CORS headers, both in a fixed static way using annotations, and in dynamic ways such as the above.

Comments Off on Spring Boot not adding CORS headers in response when using WebMvcConfigurer

STS tries to warn you when editing application.properties, if any properties do not match your configuration classes.

Unfortunately it sometimes gets out of step and does not give correct warnings.

I had a few intermittent instances of this which were cleared by refreshing/rebuilding/reloading.

However one persistent one was that whilst Spring Boot was happy with the map[key] syntax for specifying a property for a map entry, the IDE continued to give a warning on this.

In the end I could not resolve this, but using the map.key syntax instead was fine and the IDE was happy with this and did not give warnings.

The only real need for the [] syntax would be to support keys with special characters in like “.”, but in my case this was not an issue and I would normally avoid this anyway if at all possible.

Comments Off on Spring Tools Suite shows inconsistent warnings re applications.properties entries.

I was using @Configuration on a configuration class in order to load its properties from application.properties.

This is detailed in this post here.

As per the post, Spring Boot supports lists and maps in the way you would expect, and handles nested objects including Collections such as maps and lists.

It can therefore handle a complete object graph of configuration properties in a clean manner, and also happily supports generics too.

Map keys can be specified either using the “.key” syntax, or the bracketed [key] syntax (which is also used with numeric values to create lists).

The problem I hit was that a map property group, used to create mock response objects keyed on a token string, was being completely ignored even though correctly specified in application.properties.

There were no errors or messages about this the log, even when debug logging was turned on – Spring appeared to be just ignoring the properties completely.

After some significant head banging the problem was trivial.

I was using Lombok to eliminate boiler plate, and both the map class and its descendants  had Lombok @AllArgsContructors and static factory methods for my own object creation.

However this meant that they did not have a no args constructor as I had not specified one. I did not need one, but Spring Boot absolutely relies on this to work!

Once I created the required constructor via @NoArgsConstructor, everything worked fine.

Hats off to Spring for this excellent way to manage config as a nice object graph, but it would be useful to have some kind of warning when a target class does not have a no args constructor!

Comments Off on Spring Boot @Configuration class ignoring some application.properties entries

This is a collection of useful notes and post/article references on ideas for a suitable new Java stack:-

http://blogs.sun.com/enterprisetechtips/entry/using_cdi_and_dependency_injection

http://stackoverflow.com/questions/2270379/differences-between-java-ee-6-cdi-implementations

http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html#d0e4910

http://stackoverflow.com/questions/2499323/jee6-vs-spring-3-stack

No Comments »

This post is to explore best practice in this area.

The reason is that I am looking at a stack based on JSF/ICEfaces or PrimeFaces/Tomcat/JPA, as I have a project in mind to run in a hosted environment and Tomcat hosting is easier and cheaper than JBoss/Glassfish hosting.

Spring’s JPATemplate looks useful, but ties you to a Spring standard rather than an open (JPA) one which is vendor independent.

I am always wary when I read in a vendor’s documentation that “such and such an interface abstracts all the other interfaces used by other vendors/standards etc.”
Whilst of course abstraction is a good thing, you do end up tied to the abstraction interface and so need to be aware of the implications of this!

On face value (and I have not explored this at all yet as I am just starting to look at Spring) it seems a backwards step to encapsulate a platform/container independent standard (JPA) which has cross platform support with a platform/container specific one (Spring)?

This post (which I have yet to explore in detail) suggests that it is cleaner not to use Spring’s JPA support classes, which makes sense to me.

The True Way Of Developing Applications has been disturbed and that is damn good. For starters, please take a moment to read these articles in order:

Getting started with JPA and Spring
JPA Annotations Guide (broken link)
Advanced JPA with spring

• What will happen if you do:
• No more need for hibernate mapping files; everything will work from annotations, persistent classes are automagically discovered, and greenfield projects can have the database automatically generated. Controller interceptors can be substituted with Transaction annotations, which is much easier to understand and maintain. Spring will generate interceptors anyway but at least you do not have to be so aware of them.
• No more need of JpaDaoSupport and JpaTemplate. They were a great commodity with JDBC and raw Hibernate, but with JPA it’s cleaner if you do not use the support classes.
• Do not forget to make your test classes extend AbstractJpaTests so that Spring can inject your attributes.

 
I will continue to post links and discusssions here as I explore it in more detail.

No Comments »