One of the first things I wanted to do when I started working for Stormpath was to integrate it with JHipster. My reasoning was twofold: 1) I wanted to make it easy to integrate Stormpath in a JHipster application and 2) I view JHipster-generated applications as more “real world” than your average greenfield application. They’re more like an app that someone has been maintaining for several months than a greenfield app.
JHipster is a Yeoman generator that creates a Spring Boot application with an AngularJS UI. I’ve used both frameworks since 2013. When I found JHipster in 2014, I liked it so much I decided to write a book about it. The JHipster Mini-Book was first published on InfoQ in October 2015. I’ve since updated the book and there should be a new release in the next couple of weeks.
You can easily deploy this example to your own Heroku account – including the provisioning of a Stormpath account – by clicking the Heroku button below. Make sure you’re signed into your Heroku account before clicking this button or you’ll be prompted to create a new account.
TIP: Heroku’s documentation explains how to create your own deploy to Heroku button.
After I got the example application working, I turned my findings into a Stormpath module for JHipster. Today I’m proud to announce this module is ready for public consumption! It’s very much an alpha release, but it will get you up and running with Stormpath in seconds.
This module configures your JHipster application to use the following Stormpath features:
- User Registration
- Forgot Password
Features we hope to add in a future release:
- Change Password
- User Management
To show you example what changes when you run this module, I modifed the jhipster-stormpath-example project, checked it into GitHub, then created a PR with the module’s changes. You can see from the screenshot below that this module removes a lot more code than it adds.
You can find the source code for this module on GitHub. It’s a Yeoman sub-generator that leverages JHipster’s variables and functions to alter, add, and remove files. The real meat of the module is contained in its index.js. Also, it contains a simple unit test and a few Travis CI scenarios that makes sure it works on apps with different combinations. Thanks to Pascal Grimaud for his help with testing and Travis issues.
- Spring Boot startup issue: spring cache instance cannot be null. This happened when I first integrated Stormpath and tried to start the application. This was very annoying and took me a while to debug and figure out which caches I needed in my
ehcache.xmlfile. I created an issue for this in our Java SDK. The good news is Hazelcast works without any configuration.
- The Stormpath AngularJS SDK expects HTML5 mode. In the JHipster module, I worked around this by overriding the templates for each directive. I also contributed a fix to the AngularJS SDK.
- The AngularJS SDK’s if-user-in-group directive doesn’t work with the Java SDK versions <= 1.1.1. It’s been fixed in 1.1.2.
- The Stormpath AngularJS SDK allows you to limit access to UI-Router states using
sp.authorize.group. However, JHipster expects
data.authorities. To make our integration work with JHipster’s entity sub-generator, we added support for JHipster’s configuration.
Earlier I mentioned we plan to add internationalization and user management features to the Stormpath module to make it better.
Labels, messages and errors in Stormpath’s Angular templates are not translated by default. Adding angular-translate could solve this. In the meantime, users can modify the generated Stormpath templates.
Figure out how to embed user management in an application. This will be largely powered by AngularJS and might require some changes to our Spring Boot support to proxy the requests to Stormpath’s REST API. For now I’ve added the following placeholders as issues against our AngularJS SDK.
- Add change password example: #179
- Add update user settings example: #180
- Add user management example: #181
One of the things that’s likely to come up is how to handle relationships to
User from entities. JHipster has a
User.java entity and I’m still not sure how to “bridge the gap” between Stormpath’s user and the one stored in the app database. It’s almost like we need a
UserRepository that is Stormpath-aware or some other way that users can create one-to-many and many-to-many relationships with
I learned a lot by integrating Stormpath into a JHipster-generated application. While I did run into a few issues, all were solvable and our SDKs are better because of it. It was also fun to create and release my first npm module. Testing the project with Travis CI and testing all the scenarios was a great way to find bugs and fix them.
If you’re a JHipster user and would like to try Stormpath, please give this module a try! If you run into problems, please enter an issue or post your question to Stack Overflow with the “jhipster” and “stormpath” tags.