feat(dashboards): Add open graph metadata for dashboards

[worldlyjohn]

SUMMARY

• include Open Graph metadata in SPA template
• supply dashboard title and description to dashboard and embedded views
• Note: Since dashboards are behind auth -- third party apps that aren't already authenticated -- will not be able to unfurl. This PR however is a pre-req for future third-party app unfurling of urls once auth can be handled.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

• Open a Dashboard
• View source and confirm the presence of og:title tags (or paste into slack to render)

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[korbit-ai]

Review by Korbit AI

Korbit automatically attempts to detect when you fix issues in new commits.

Category	Issue	Status
	Inconsistent Meta Tag Formatting ▹ view	🧠 Not in standard

Files scanned

​

File Path	Reviewed
superset/templates/superset/spa.html	✅
superset/embedded/view.py	✅
superset/views/core.py	✅

Explore our documentation to understand the languages and file types we support and the files we ignore.

Check out our docs on how you can make Korbit work best for you and your team.

Loving Korbit!? Share us on LinkedIn Reddit and X

[github-actions]

Congrats on making your first PR and thank you for contributing to Superset! 🎉 ❤️

We hope to see you in our Slack community too! Not signed up? Use our Slack App to self-register.

[mistercrunch]

Oh nice, actual good use of server-side html generation!

Wondering a few things ->

• does it even work for embedded? I doubt Slack will process the iframe if there's one and bubble up the meta?
• how does auth work here? I'd assume the in-slack browser wouldn't have access to the dashboard, unless maybe if it's public?

[worldlyjohn]

• how does auth work here? I'd assume the in-slack browser wouldn't have access to the dashboard, unless maybe if it's public?

@mistercrunch You're right, Slack’s crawler is not logged in, so it receives this redirect and never reaches the dashboard page.

Upon further research, unfurling works with some analytics tools because those like Mixpanel have developed Slack integrations that provide an access token.

Appears a similar Preset/Superset Slack integration would need to handle auth before this scope of work is relevant 🤷‍♂️ .

Alternative approaches:

• Wrap metadata behind a small “unfurl” view. Create a lightweight endpoint that serves only the Open Graph tags (and optional screenshot) without loading the full application. Slack would be sent to this endpoint via the public link. Downside is this could leak possibly confidential dashboard titles to anyone with a dashboard link.
• Provide Slack access via a token. Use the existing guest-token mechanism (SecurityRestApi.guest_token) to generate a short-lived token that authorizes Slack to fetch only the metadata. The request could include ?guest_token=<token> so the crawler receives the correct page without a redirect. Downside is a request for this link that cloaks itself as a Slack request (modifying HTTP request headers perhaps) to retrieve the dashboard title.
• Develop a Superset Slack integration.

wdyt? (I likely don't have the bandwidth atm to work on these alternative paths, but this unfurling support would be a welcomed addition as we roll out Superset/Preset to our 1000 person org next month) :)

[mistercrunch]

I want to highlight some of the security concerns and mitigation mechanisms.

• Object metadata can be sensitive in some contexts: just noting that a dashboard can be titled Next Earning Calls: Crushing it!!!! and that's potentially sensitive, also paired with the fact that we use autonumber ids, an attacker could essentially fetch a list of dashboard / chart titles on a Superset instance
• Public instances: if/when an instance is public, this is even more sensitive - thinking of Preset here or any internet-visible instance
• Superset in-VPN: assuming the user is in some sort of VPN, Slack should be able to call and unfurl through that same VPN, maybe that's where this feature is "ok", where someone could decide that dashboard names are public within their network (?) Still somewhat dubious... Users might not know that while creating a new dashboard.
• RBAC concerns: currently Superset only shows you charts/dashboards that are accessible by you, meaning Next Earning Calls: Crushing IT!!!! could be a hazard even internally: knowing about the existence of a specific dashboard title could be an issue within the VPN walled garden

Given that:

• Slack app + impersonation (solving for RBAC concerns) seems required for most environment
• About creating a public/insecure endpoint that serves logged off metadata: maybe a feature flag could mitigate this configuration for instances that consider dashboard names public within their VPN. Flag should come as false by default and come with a clear disclaimer
• About squeezing metadata in headers, totally fine by me, but Slack won't see them, though it's a pre-req building block for the Slack app to work. Say if you build your own Slack app, you'll need that and there's no arm in adding those meta tags today.

About the Slack app:

• probably needs to be aligned with your auth mechanism? so if you use oauth, or username/password or Okta or whatevs, the Slack app might be different, probably hard to build one that works for everyone
• if anything, an open source implementation as a reference for the community would be great. Ideally lives outside of the main repo

[worldlyjohn]

it's a pre-req building block for the Slack app to work

Agree here. In this case, I think this PR is properly scoped.
I changed the title to reflect the new scope

[rusackas]

Code LGTM, but I'm not sure about @mistercrunch's concern as to whether or not this poses a form of security risk with revealing dashboard titles and such. I'll cc @dpgaspar for good measure.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.04%. Comparing base (76d897e) to head (ddf2083).
Report is 1898 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #33550       +/-   ##
===========================================
+ Coverage   60.48%   83.04%   +22.55%     
===========================================
  Files        1931      553     -1378     
  Lines       76236    39999    -36237     
  Branches     8568        0     -8568     
===========================================
- Hits        46114    33217    -12897     
+ Misses      28017     6782    -21235     
+ Partials     2105        0     -2105     

Flag	Coverage Δ
hive	?
javascript	?
mysql	75.38% <100.00%> (?)
postgres	75.44% <100.00%> (?)
presto	52.68% <0.00%> (-1.12%)	⬇️
python	83.04% <100.00%> (+19.53%)	⬆️
sqlite	74.93% <100.00%> (?)
unit	61.30% <0.00%> (+3.67%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mistercrunch]

From my understanding I think it's safe where that page should only render if the user has access to the dashboard. What would be a security concern is if we returned metadata to an unauthenticated user to enable [unauthenticated] Slack (and everything else).

About touching superset/embedded/view.py I don't think the meta tags will make it through an iframe but probably doesn't hurt.