Context Based Serialization

June 20, 2019

Context Based Serialization

Context is an important part of the way you serve your data and can mean many different things for your application. In this case we're talking about the situations or instances in which people are requesting data. In an application, you typically serve data to a client of some sort. Now whether or not your API is public or private, there are fields that your entities have that may need to be private. An entity is just a type of data, for example, the User entity if you weren't already aware. 

Three Tier Architecture

In your average three tier environment, you have a data server (Mongo, MySQL, Postgres), web server (Business Logic), and the client application (Usually Javascript Based). The web server is meant to do all of the heavy lifting so the browser can stay nice and light. The web browser is for presentation logic and meant to stay small but isn't always this way. Back to context based serialization, your web server should be in charge of hiding certain data so the user can't access confidential information. In an environment where your API is public, it's much more important to be secure about your data. A couple of weeks ago, DevWars had an issue where through a simple API call, users could see other user's email addresses due to a lack of planning. This was critical and required a future proof plan.

  The Solution

The solution to this problem sounds very simple, just hide the data when it's being sent as JSON right? Well you see it's not always that simple, there are many situations where certain data needs to be available to certain users. An example of this is when a user is on his profile page, he or she should be able to see his or her email address. In public API calls, this shouldn't be the case, confidential information must be hidden. We needed to design a strategy which we could use in the future to make sure data can be hidden in the right context. Most of the time, user's data is to be shown based on who is requesting the data. So DevWars admins should be able to see some relatively private data and the current user requesting the data should be able to see his own data. If you designed your application well, it shouldn't be too much to implement. The Jackson library for JSON serialization in Java has custom serialization strategies so when I serialize a user, only show their public data unless the user requesting the data is authorized to see the private data.

Ease in the Future

In Java, you can put what are called annotations (Prefixed with an at symbol) on most 'things'. This variable declaration is in the User class. At JSON serialization time, the data will be looked at and if it has that annotation, it will check if the current user requesting the data is authorized to see it. If you haven't noticed the obvious flaw here, it's that what if you have other things that have private data, how are you gonna hide that. An example is the Warrior class, how is the serialization strategy to know that their company is private data and which user to tie it to? The answer is in the Warrior class, there is a User field to identify the user that owns the warrior object. Here is some example code to show you how easy it is.

These variable declarations exist in the Warrior class. The user variable is to show which user owns it for the database relationship. The date of birth is a field which we want to keep private so we mark it with the same annotation and give it the name of the field to tie the user to. Now at serialization time, we know what to compare the user requesting the data to.


Hide your data based on who's requesting it.