Personalize your Embedded Charts with Custom Filters
MongoDB Charts now allows developers to embed charts with customizable filters, resulting in more personalized visualizations for users.
A couple of months ago we introduced embedding in MongoDB Charts, and I showed you how to use both anonymous and verified signature authentication modes to put some snazzy visualizations into a blog post. Since then we’ve seen many great examples of developers adding beautiful charts to their applications with next to no coding effort required. However one big limitation with Charts embedding was that every user loading an embedded chart always saw the exact same information. There wasn’t any way to provide users with a personalized view of data based on their identity or their preferences.
Today we are excited to show off some improvements to embedding in MongoDB Charts that make it possible to build a much more personalized experience. First and foremost, a developer can now specify a custom filter to use when rendering an embedded chart, telling Charts to load a subset of the available data that is appropriate for the current user. Here are just a few examples of how you could use this:
- Showing a user’s own personal fitness data, from a collection containing data for many users
- Showing a sales rep just the data pertaining to their own region, from a collection containing data for multiple regions
- Showing a user some data for a specific time period, chosen by the user from a dropdown control.
Here’s an example of the third scenario, where you as the user can decide what date range you want to see from this dataset tracking the temperature in Sydney.
Number of days to show:
The crux of this feature is that the embedding URL loaded into the IFRAME can now specify a filter query string parameter whose value is an MQL filter document, like { userId: ‘tomh’ }. This filter (in addition to any filters baked into the chart definition) is applied at the time the chart is rendered. For security reasons, we only allow this feature to be used with the Verified Signature authentication model. If it were enabled for Unauthenticated embedded charts, anyone could apply whatever filters they wanted to a chart, potentially uncovering sensitive details from seemingly benign aggregated data. By requiring the Verified Signature model, you can make sure that users can only filter the chart in a way that you allow, or not at all.
Another limitation of the initial release of embedding was that there was no way of refreshing a chart without reloading the entire IFRAME. We’ve also addressed this in our newest release, by allowing developers to specify an optional autorefresh query parameter in the IFRAME URL. If set to a number greater than or equal to 10, the chart will automatically reload after the specified number of seconds have elapsed. Unlike the filter parameter, autorefresh can be used with Unauthenticated charts as well as with the Verified Signature model.
A Deeper Dive
The Verified Signature authentication model for Charts embedding is designed to ensure that the IFRAME URL for a chart was generated by the developer’s code and not tampered with by an end user. It works by generating an HMAC digital signature for the URL, signed using the Embedding Key that is available in the Charts Admin Settings page. For this method to be secure, the Embedding Key must never be available to the client, so the signing must be done in server-side code.
To implement custom filters on an embedded chart, you need to extend the server-side code to add the MQL filter document to your query string, before that payload is digitally signed with the Embedding Key. To maintain security, you should not accept complete query documents from the browser. Instead, you should either create the full query document on the server, such as filtering based on the user ID of the logged in user, or generate a document from sanitized user input.
In the example embedded in this article, the dropdown control provides options controlling the number of days of weather data to view. The chosen value is passed to the backend function which generates the signed URL—in this case I’m using a MongoDB Stitch function, but you’re free to use your choice of backend. The backend function then validates that the number of days is within the expected range, and if so creates a filter document like this:
const FILTER_DOCUMENT = { observationDate : { $gte: { $date: new Date(new Date() - numDays * 24 * 60 * 60 * 1000).getTime()}}};
That filter document is then URL encoded, appended to the end of the query string, and the entire URL is then signed using the Embedding Key and returned back to the browser to load into an IFRAME.
To see complete examples of how to use both filtering and autorefresh with embedding, the Charts Embedding Examples have been updated, with samples available for Node.js, C#, Python, Java, PHP and MongoDB Stitch. We hope you find these updates a great addition to embedding in MongoDB Charts!