Managing session information in web tokens in Delphi MVC Framework (Part 1)

This is the first part of the series leading to using web tokens in Delphi MVC Framework.

This is the first part of the series leading to using web tokens in Delphi MVC Framework.

So why this blog?

This is blog is an outcome of the problems I needed to solve when writing my web application. I will first try and define the problem and then show you how you can over come the issue of session management.

The whole thing started with writing microservices for my web application using Delphi. Quite sometime back, we decided to move away from the monolithic approach and decided to break up the application in individual self sufficient services catering to very specific business processes. The whole thing made sense as it would force us to decouple our code, provide better maintenance and resilience for the application. All good.

If you have done any microservices development, you will understand the issue we encountered. A single client (say a browser) needs to talk to multiple application. Normally, you would sign in the client using say.. an authentication service. Once the client is signed in, you would need a way to share that information with rest of the services, right? The problem with that is while the auth service will know who has signed in, the rest of the apps wont (since they are running in their own memory space). So what can you do in that case?

Use the session id that’s generated by DMVC and store it in an shared space (like a database).

You probably know that DMVC generates a unique session id for every client (context) and therefore you can use that session id and add it to the database that’s common to all other microservices.

If the same client makes a call to another microservice, you can look up the session in that microservice against the database where the auth services stored the data. If you find that session id, then you know that it could only be there if auth service put it… and the auth service would only put if the user supplied the right log in information so the session id is valid and the user is authenticated, therefore the next service app would happily process the call.

While this approach definitely works, it has its drawbacks. For one, for every call, it increases the load on the database or any persistence method you plan to use, making the system slower than it needs to be. And that’s where web tokens come into the picture.

In the next part, I will lay out how web tokens work, and how they can help you do away with managing external persistence mechanisms for sharing session information between multiple microservices without compromising security.

One Reply on “Managing session information in web tokens in Delphi MVC Framework (Part 1)”

Leave a Reply

Your email address will not be published. Required fields are marked *