Sense check on embedding solution, locked paramaters and caching

Get Help
1

I want to sense check a solution I’ve currently built, and want to make sure this will work as planned.

I’m using the open source version and have built all my Models with an Org ID field, allowing me to map all data to a specific customer in our database.

I’m then using the dashboard embed to iframe the dashboard into a React front-end, for our customers.

I’ve added Org ID as a locked parameter, so the page the dashboard is embedded on will only ever pass the Org ID of the currently logged in Org admin, meaning they will only ever see their data. I’ve defaulted this value to 0 which will never return on Org ID, so if anything goes wrong, they don’t see any other Org’s data.

I also have a second dashboard in the same instance which is embedded in the admin area of the product, viewable by admins. This doesn’t filter data in the same way, as admins see reports for all Orgs across the platform.

My concerns are caching and deployment, which I’d love to sense check.

What caching settings should I be using? I want to optimize performance, but could users ever see other Orgs cached data? How do locked parameters bust any caching?

In terms of managing this once live, what’s the best approach to ensure any newer changes don’t expose other Org data, and to manage higher risk changes? Assume I’m either best of cloning the Dashboard to make changes, then switching the embedded Dashboard ID in the app with each major release, or creating questions on a different Dashboard and only moving them over when tested and ready?

Is there anything else I should be aware of with my approach?

Note, we’ve so far avoided the Pro version, but I’m seeing the limits with the Metabase logo and styling limitations that are helping me put a good case to the business owner to upgrade.

2

I would hold off on caching until there is a demonstrated performance issue. Caching add a complication (and I don’t think you want to get to having to cache every orgid/tenant/customer). Certainly test it if you like but unless your database accesses are expensive (time consuming or wallet consuming) it may not be a win. You likely have an index on org id in the DB so it shouldn’t have trouble quickly returning data.

As far as managing risk, in OSS the best you can do is a test environment and 3rd party tools to copy dashboards around. Pro gets you remote sync, so you can Git your way to dashboard copies. Pro also brings built-in row-level security using a key like org ids but it also brings user licensing costs (each org id would need its own user which must be licensed).

Its cheaper if you can run with guest embedding and generate your own JWTs using your own code, which isn’t likely to change.