During writing the last six parts of this article series a lot has happened. From absolutely zero the building blocks of a user management application had been developed. In this last article, I’d like to show you how to assemble the pieces in order to get the app working. Some functionalities are still missing and I’m still working on the first release to make make it feature complete, but the very basics are available now.
Last time I added username and password based authentication with using Spring Security. Should you have missed the that, I notice here that JWT tokens were issued upon a successful login and validated for subsequent requests. Creating long-lived JWTs isn’t practical, as they’re self contained and there’s no way to revoke them. If tokens are stolen all bets are off. For that reason, I wanted to add the classic remember-me style authentication with persistent tokens. Remember-me tokens are stored in cookies as JWTs as the first line of defense, however they are also persisted to the database and their lifecycle is being tracked.
So far the business logic, data access layer and the front controllers had been build, however enforcing authentication was completely missing. As Spring Security became the de-facto standard when is comes to building authentication and authorization into a Java web application, I’ll be using that. In this fifth part I show you how Spring Security can be used with JWT tokens, another technology gaining traction nowadays.
In the previous part the data access layer along with the repositories were implemented, before that the domain model without having to rely on any framework specific class or feature and now time has come to add REST controllers on the top of that.
In the previous part there was fair amount coding involved over the course of implementing the domain model, which comprises all the logic a user registration process needs. In this third post, I went ahead and added a concrete JPA-based implementation of UserRepository, a JPA support module and some test cases.
In my previous post I defined the requirements of a user management microservice and designed the initial domain model of it. Getting lots of positive energy from the community and many valuable comments on Reddit ensured me, that it’s worth going on with the project. In this second part, I’ll detail how the domain model got implemented and what decisions were made behind the code.
In this first part we define the requirements against the application, its initial domain model and that REST API which its front-end will be using. We start off by defining the user stories for registering and managing users.
When using Spring Data MongoDB IDs can be automatically generated for documents provided that you’re using an ObjectId, String or BigInteger as the underlying type. What if you would like to use some other, non-autogeneratable type for IDs?
During the investigation of a slowdown in a back-end Spring application, I found an interesting side-effect of using class-level @Transactional annotations on Groovy-based services. If you’re using bare Groovy with Spring 4.2 (or below) and concerned about your back-end’s performance, keep reading.