Metabase CORS and CSP headers

staypath

@girish From what I've read, it seems the Metabase position is "use whatever reverse proxy you have in front of Metabase to add CORS as required". Metabase does seem to insert CSP headers for their embedded dashboards.

A mitigating factor here is that I'm embedding the Metabase dashboard into an iFrame component in Retool, which I'm sure is complicating things a bit:

https://retool.com/components/iframe

However, the ability to modify CORS in nginx the same way you allow us to modify CSP would be useful.

Thanks

girish

@staypath Per the code at https://github.com/metabase/metabase/blob/036de06748d6460b8f9d9f2103d50e02c9df9e52/src/metabase/server/middleware/security.clj#L131 , we can tweak embedding-app-origin for CORS . But I think it's only in the metabase pro as per https://www.metabase.com/docs/latest/embedding/interactive-embedding#enabling-interactive-embedding-in-metabase

BTW, there is some embedding setting in /admin/settings/embedding-in-other-applications :

staypath

Thank you for looking into it. You are correct, the MB_EMBEDDING_APP_ORIGIN env variable is for users doing interactive embedding of Metabase, which is a Pro/Enterprise features and not what we are doing. We are doing public sharing, which is a simple iFrame.

Here are the response headers - Metabase doesn't include CORS. CleanShot 2024-03-28 at 14.45.01@2x.png

I do not think this is a problem in Cloudron, I was only asking if there is a way to allow Cloudron users to override or provide CORS headers in nginx without having to manually override the nginx config.

Thank you

girish

@staypath currently, there is no way to edit CORS headers at the reverse proxy. What you did (to edit the files directly) is the correct approach. But as you found out, app updates will remove that config.

I think for Cloudron itself, we won't add a way to edit CORS via the UI. Usually, this is provided by the app and should be provided by the app. Users and packagers should really not be editing CORS configuration directly because only the app author knows the security implications.

But with my Cloudron user hat on, I understand that sometimes we are put in these positions where one is forced to hack around things Maybe we can include user.conf optionally in app nginx configs?

staypath

If adding user.conf customization would persist settings like headers in nginx, that might be a good feature. Thanks again.

girish

@staypath was discussing this internally and we got a bit confused by your earlier comment in #3 . Do you know how/why adding CORS fixed your embedding issue.

Isn't embedding ~~mattermost~~ metabase about adding an IFRAME? If so, this only involves fixing the CSP header and the CORS headers should have no relevance. Did we misunderstand something ? CORS is only applicable if a website frontend, which is not ~~mattermost~~ metabase, is making API calls to ~~mattermost~~ metabase.

staypath

Thanks for the reply. We are embedding Metabase, not Mattermost. I agree with you, normally CORS would not apply, but as I mentioned previously, we are embedding Metabase within a Retool iFrame component. Something about how Retool fetches the iFrame content is making it appear to the browser that it should check for CORS headers. Since CORS headers don't exist, the browser refuses to load the iFrame. I think there are two questions here:

is CORS even required in this scenario? Maybe it shouldn't be by design, but the Retool iFrame component will not load the Metabase content without CORS headers in place
in edge cases like this, would the ability to customize nginx headers in Cloudron user.conf solve the issue?

Thanks

girish

@staypath whooops sorry, that was an unintentionaly typo. I meant metabase all along. As for retool, I am just looking at what that is.

girish

A simple iframe test works for me in Surfer:

    <!DOCTYPE html>    
    <html>    
    <body>    
    <h2>HTML Iframes example</h2>    
    <p>Use the height and width attributes to specify the size of the iframe:</p>    
    <iframe src="https://metabase.smartserver.io/public/dashboard/5124c74d-ab16-42d7-b1a1-68b774e5dd66" height="500" width="500"></iframe>    
    </body>    
    </html>

Not sure what retool is doing.

girish

OK, found the problem . @staypath retool is removing the allow-same-origin from the iframe . See https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#allow-same-origin . This makes API calls in the IFRAME appear as cross origin. Adding it manually in web inspector, makes retool show it:

girish

Ah, found it. Just check this option in retool (Interaction -> Enable Storage and cookies) and it works.

staypath

I really appreciate you looking into this. You have gone above and beyond, so thank you again. I saw the Storage and Cookies option in the Retool docs as well, and strangely, my Retool instance does not have this option. I will open a support ticket with Retool to figure out why this option is missing. Thank you again for the help with troubleshooting.
CleanShot 2024-04-06 at 07.06.44@2x.png

girish

@staypath ah interesting. I am using the cloud version. Maybe you are on selfhosted?

staypath

@girish Yes, maybe that is the difference. I am using self-hosted Retool.

staypath

@girish Just closing out this discussion. For reference, here is when the change was introduced to Retool that caused the issue with loading the iframe:

https://docs.retool.com/releases/legacy/3.22#:~:text=Disabled Storage and cookies

Thanks again.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

Metabase CORS and CSP headers