Previously we have managed to finally get rid of that Session object and transform our RESTful API security to leverage a stateless authentication solution. We replaced our beloved JSESSIONID with a simple string of text, a token, that allowed us to identify a user. But the solution we used is not secure at all. We still need to find a token with the right characteristics to be safe enough in this world of leaks and breaches. Enter JWTs…
Last time we reviewed how to quickly set up stateful authentication on our Spring-based project. That’s very nice ‘n’ all, and in many cases you won’t need anything more. However shouldn’t we try to get rid of that session-based dependency and attempt to move to a REST-friendly stateless authentication solution? Let’s begin…
After a quick introduction we are now ready to begin our journey towards stateless authentication for RESTful APIs… by setting up a stateful example. Yes I know, but we have to start somewhere, right? In this part we’ll set up our project and code a couple of simple endpoints. One of those will be secured using Spring Security’s session-based authentication.
By now “stateful” or session-based authentication is pretty much well-accepted. Frameworks such as Spring Security or Apache Shiro make it really easy to implement a decent solution in just a few easy steps. I previously discussed how to secure a Spring-based REST API using Spring Security for authentication, CSRF protection and CORS. But in some cases, session-based security might not be good enough…
You always end up coming to it. It’s inevitable. It cannot be helped. Yep, it’s time to write a custom validator for your shiny new Angular application. So how do you do that in Angular 4? And more importantly: how do you test it?
I sure didn’t expect anything on that particular day, but Coloringbook’s album just took me by surprise: I remember stopping what I was doing and go “Holy sh!t, what’s that!”. Only one way to cover this one: going full Gonzo. Buy the ticket. Take the ride.
In July 2016 The Impossebulls released their follow-up to their 2014 classic “Everything Has Changed; Nothing Is Different”. Almost a year later, after repeated listening, I finally decided to take some time and talk about it.
Software companies used to have one goal: to develop efficient applications that users liked. When people switched from desktop to SaaS / web applications, companies were forced to focus on security to avoid being hacked. Now they will have a new mission: to ensure the privacy of their users. At any costs.
It’s 8 PM on a Saturday and you get a call from your project manager asking if you could quickly modify a project’s code and deploy it in production. You don’t feel okay about it? You’re absolutely right!
After years of developing software by (incorrectly) applying the Scrum methodology, I have come to this conclusion: Scrum is the new death march. Or rather, Scrum does more harm than good when it’s mindlessly requested by managers who are merely trying to show how modern and trendy their development teams are.