Skip navigation

Category Archives: Framework

If any posts have to do with using any software frameworks, libraries, UI components, etc.

Right now, I’m spending some of my free time getting up to speed with Spring Boot. Opinionated frameworks like Spring seem like they’d be a great way to build some quick prototypes for some ideas I’ve got bouncing around my head without having to go through the learning curve a whole new language. I’m already overwhelmed enough with my operations (Linux, networking, security, application servers, etc) and Unity automation for work. And now I’m throwing some AWS into the mix for some side work with a friend.

In my experimentation with Spring Boot, I threw together a quick cat fact web service. Running mvn spring-boot:run and accessing the endpoint at http://localhost:8080/getcatfact returns some super-simple JSON with a random cat fact. Yay kitties!

I created another package, based on the Spring Boot tutorial, designed to be a “Hello, World” example. When I run the application, everything starts up fine, and the Cat Fact endpoint still works. But trying to access the http://localhost:8080/greeting endpoint results in a weird “White Label Error Page”. After some internet searching, I found a decent answer. It seems the error is related to having my packages at the wrong level. Spring will search for and load Boot applications at the initial application’s package level and any sub-packages. Since the net.bencarson.catfact and net.bencarson.hello packages were siblings and didn’t share a parent, it was obvious how to fix my problem. I just needed to create a common parent SpringBootApplication and package and move these existing applications underneath.

I created a new class for net.bencarson.services.MyServicesApplication and moved the catfacts and hello packages under the new net.bencarson.services package, the application was still throwing the White Label error for ‘greeting’.

Proper application hierarchy for Spring Boot
Moved the Spring applications under a parent package and application

The final piece I was missing was that I needed to modify my pom.xml. Inside, I had to change the <start-class> element.

<start-class>net.bencarson.services.MyServicesApplication</start-class>

Now the service starts correctly and both ‘catfacts’ and ‘greeting’ endpoints are accessible!

Our CTO came to me recently with the results of a PCI audit. One area of non-compliance that the audit discovered was the need to have users log in only through a SSL encrypted gateway. I set about finding a way to accomplish this with Liferay. Thankfully, it was a pretty easy change and didn’t require any custom log in code (as I initially feared.)

At first, I just happened to come across a relevant property in my portal-ext.properties file.

servlet.always.encrypt=false

On my local machine, I changed this value to true, restarted the server, and all traffic on my local server redirects to the ssl encrypted version on port 8181!

“Hooray”, I thought. “I’m done!” I talked to our Ops team to get the changes made in our other environments and he promptly burst my this-is-too-easy bubble. “Why is it encrypting our marketing site? We shouldn’t be encrypting everything, just the stuff we need protected.” Damnit! Now I have to find an alternative. Fortunately for me, the same Ops guy found the relevant properties to include in our portal-ext.properties file:

#require https for login
web.server.http.port=8080
web.server.https.port=8181
company.security.auth.requires.https=true

This is exactly the technique we needed. Our site doesn’t encrypt any public-facing page (unless you are already logged in) and all logged-in traffic is SSL-encrypted. Liferay team really did me a solid by making this so easy to configure. Thanks girls & guys of Liferay!

I have been struggling with getting Liferay to play nicely with our OpenLDAP server for the past two days.

I finally was able to figure out my mistake this afternoon.

Liferay expects ‘user’ entries (objectClass = inetOrgPerson, in my case) to be in the following format:

objectClass = inetOrgPerson

objectClass = organizationalPerson

objectClass = person

objectClass = top

cn = beardy@liferay.com

sn = Beard

givenName = Doctor

mail = beardy@liferay.com

title = Hirsute Physician

userPassword = <whatever encryption you use>

After much struggling and cursing, I found that my trouble was with the cn=beardy@liferay.com. An email address is not allowed in this field.

Once I changed the cn to ‘beardy’, I was able to login to my Liferay portal using LDAP authentication, the user was imported to the Liferay database, blah blah blah. Everything works great now.

Probably a simple fix for an experienced LDAP administrator, but for a n00b like me, it was an infuriating minor detail that made all the difference in my portal working versus not working.

…I’ve got to find a way to add code to my blog.

 

UPDATE (06.28.2012) – I’ve found a decent enough way to do it.