If you’re a soccer fan then you must have read about the news of the proposed European Super League and its scandalous launch last Sunday and its catastrophically quick collapse less than 3 days later.
Among its many misgivings, which received all-out criticism from fans and sporting associations, was its wildly poor communication skills to – what the owners of the soccer clubs call – its “stakeholders.”
The proposal for a new super league was announced in the darkness of Sunday night via a statement. In the following 2 days, amidst widespread outstarge on the continent, there was no unravelling of the project, no spokespeople, no collaboration. Its thinness of content was locked away among the 12 owners of the clubs involved, who remained faceless during soccer’s longest 72-hour period.
The core that underpins any project is a well-organized structure of communication both internally and externally.
If we take this into the digital world of apps, the same principle holds – which is why securing content and data integrity, as well as managing levels of access and its distribution, pivotal to success.
In line with this, one of the leading content management systems, Contentful, has built request verification into its App Framework. This means that this out-of-the-box tool gives strong functionality to keep what’s important intact and in the right place.
When it comes time to develop an app through Contentful using the App Framework, what you’re actually developing is a one-page application that runs inside an iframe (or inline frame, that works inside a page to load another HTML doc within it). Great for extending your brand’s Contentful environment, apps are also ideal for constructing the business solutions of your brand.
Apps are actually broad in scope – they can be incredibly simple; and they can be quite complex, depending on how advanced you want your app to be, and what functionality you want it to have. Do you want it to be able to modify user input or make network calls to the back-end?
At the front-end, apps that make network calls at times may need a route to authenticate themselves with the back-end, of course. It’s important for authentication in order to make communication safe and secure. But building this from scratch involves a lot of hours and is difficult to implement.
To bridge this gap, Contentful developed a smooth way for developers to secure the communication between the front- and back-end while working on apps. Contentful calls this Request Verification.
So how exactly does this work? And what does it look like?
Inside of Contentful, when a request is verified, the original message’s integrity is secured using a secret that you provide – also known as “signing a request.” These act as a security mechanism that is used in many software apps. And so when a request is signed, the back-end knows this “signing secret” can be used to verify that a request came from your app while being displayed in the Contentful web app. At the other end, this also means that the back-end is able to reject a request that is made but that isn’t verified, or when a signature is simply invalid.
Contentful’s request verification claims an abundance of use cases. Take, for example, the back-end, which can provide users the access to private information in a secure way, restricting who is able to carry out certain actions, as well as make sure that only apps you’ve allowed are actually communicating with the back-end.
Here’s one example
There’s nothing easier than to take a look at a concrete example. And if you’re like me, you’re a visual learner, and benefit from clear and concise examples.
Consider the following scenario: you’re building an app with a button in the Contentful web app which, through the back-end, will be able to trigger a flow to modify other data in Contentful. Yet you really want to make sure that the person who began this request maintains their ability to access the data.
So when you implement a request verification on the front-end, you are making sure that when it’s sent to the back-end, you’re able to verify its authenticity – and either permit or reject the request.
As we see in the code, we can see that when we write the network request, we can use the software development kit method “signRequest” to create an object that includes all of the data, and will include additional headers – which contain useful security data such as the signature.
Afterwards, we can make sure that the back-end is properly able to read the request and be able to allow or reject the request, based on the authenticity of the signature. Here’s the example of this.
As you can see this example uses the Node.js framework Express to run this server and listen for data on an endpoint. The moment we receive an event like this, we’ll use the node-apps-toolkit function “verifyRequest” to approve the message.
And bear in mind that we can complete a request verification using any back-end language that is able to receive HTTP requests.