fix(Embedded): Skip CSRF validation for dashboard download endpoints

[Vitor-Avila]

SUMMARY

#29953 removed the CSRF requirement for endpoints used to download a dashboard as PNG/PDF, so that these work in embedded mode.

This PR changes the FF validation logic for these endpoints from using before_request to a new decorator, as before_request was causing issues to the WTF_CSRF_EXEMPT_LIST config.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

No UI changes.

TESTING INSTRUCTIONS

1. Have async dashboard screenshot download configured.
2. Access an embedded dashboard and validate that the PDF download works.

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	Fix Detected
	Incorrect HTTP Status Code for Disabled Features ▹ view

Files scanned

​

File Path	Reviewed
superset/views/base_api.py	✅
superset/dashboards/api.py	✅

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

Need a new review? Comment /korbit-review on this PR and I'll review your latest changes.

Korbit Guide: Usage and Customization

Interacting with Korbit

• You can manually ask Korbit to review your PR using the /korbit-review command in a comment at the root of your PR.
• You can ask Korbit to generate a new PR description using the /korbit-generate-pr-description command in any comment on your PR.
• Too many Korbit comments? I can resolve all my comment threads if you use the /korbit-resolve command in any comment on your PR.
• Chat with Korbit on issues we post by tagging @korbit-ai in your reply.
• Help train Korbit to improve your reviews by giving a 👍 or 👎 on the comments Korbit posts.

Customizing Korbit

• Check out our docs on how you can make Korbit work best for you and your team.
• Customize Korbit for your organization through the Korbit Console.

Current Korbit Configuration

General Settings

​

Setting	Value
Review Schedule	Automatic excluding drafts
Max Issue Count	10
Automatic PR Descriptions	❌

Issue Categories

​

Category	Enabled
Naming	✅
Database Operations	✅
Documentation	✅
Logging	✅
Error Handling	✅
Systems and Environment	✅
Objects and Data Structures	✅
Readability and Maintainability	✅
Asynchronous Processing	✅
Design Patterns	✅
Third-Party Libraries	✅
Performance	✅
Security	✅
Functionality	✅

Feedback and Support

• Tell us what you think of Korbit
• Schedule a call with our team
• Email us @ support@korbit.ai

Note

Korbit Pro is free for open source projects 🎉

Looking to add Korbit to your team? Get started with a free 2 week trial here

[korbit-ai]

Incorrect HTTP Status Code for Disabled Features

Tell me more

What is the issue?

The decorator returns a 404 Not Found response when feature flags are disabled, which is semantically incorrect and misleading.

Why this matters

A 404 response indicates a resource was not found, but in this case, the resource exists but is intentionally disabled. This could confuse API clients and monitoring systems trying to understand why the endpoint is not accessible.

Suggested change ∙ Feature Preview

Return a 403 Forbidden status code which better represents that the feature exists but access is not permitted:

if not all(is_feature_enabled(flag) for flag in feature_flags):
    return self.response_403()

Chat with Korbit by mentioning @korbit-ai, and give a 👍 or 👎 to help Korbit improve your reviews.

[geido]

I am thinking if we really need the couple here at this point or ENABLE_DASHBOARD_SCREENSHOT_ENDPOINTS will suffice. What's your thought? I have been meaning to remove this dependency before and this could be a good chance.

[Vitor-Avila]

@geido if we remove the requirement to have THUMBNAILS enabled for this endpoint, but then we keep it at the digest endpoint, then at the end the process would still not work unless you have both enabled.

Also, currently when you trigger a "screenshot generation" it returns the digest link, which returns a 404 status code until it's being processed. If THUMBNAILS is disabled, it would return 404 forever and users wouldn't have an easy way to spot the issue.

I think we could either:

• Remove the THUMBNAILS check for this endpoint, and then update the check on the digest endpoint to validate for either THUMBNAILS OR ENABLE_DASHBOARD_SCREENSHOT_ENDPOINTS. This way you can still download a dashboard screenshot without having THUMBNAILS FF enabled; or
• Update the other endpoint to return a different status code if the THUMBNAILS FF is disabled. Also update the frontend (if that's not the case yet) to validate if both FFs are enabled to decide if frontend or backend processing should be used.

One potential issue with the first approach is that environments with ENABLE_DASHBOARD_SCREENSHOT_ENDPOINTS enabled but THUMBNAILS disabled would still expose the digest endpoint, so it's possible that disabling THUMBNAILS FF would no longer be sufficient to remove thumbnails from displaying in the card views.

Let me know your thoughts!

[geido]

Alright. I think there is a case here to keep both. Maybe @fisjac can consider the above for the work that he is doing around screenshot generation for future improvements. Thanks for this!