Internally Hosted Draw.IO is not usable, "This content is blocked. Contact the site owner to fix the issue."

[thickconfusion]

Describe the Bug

Similar to #2285 , I am getting a gray page in Chrome that says "This content is blocked. Contact the site owner to fix the issue."

I have the following environment variables set for the container:
DRAWIO=http://172.31.1.167:8080/?embed=1&proto=json&spin=1&configure=1&stealth=1
I have also attempted to modify this environment variable:
ALLOWED_IFRAME_SOURCES=

I've tried:

• http://172.31.1.167:8080
• https://172.31.1.167:8443
• http://172.31.1.167*

The only one that "works" is if I make it ALLOWED_IFRAME_SOURCES="*", which seems like a security vulnerability even if I'm running this on a LAN.

Note: I can access the plain old Draw.IO interface just fine: http://172.31.1.167:8080, and it loads.

Steps to Reproduce

Edit a page, click the icon to work on a Draw.io image.

Expected Behaviour

I expect to load into a Draw.IO instance.

Screenshots or Additional Context

No response

Browser Details

Chrome and Edge on Windows 11

Exact BookStack Version

v24.05.2

[ssddanbrown]

Hi @thickconfusion,

You shouldn't need to adjust the iframe sources since BookStack will look to automatically add any custom drawio URL, where set, to the CSP rules. Maybe our custom handling is tripping up any additional rules you're adding.

It does look though like we are not currently handling scenarios where non-protocol-standard ports are used.
I've marked this to be tested for next patch, against a custom-ported drawio instance.

Dev reference

BookStack/app/Util/CspService.php

Line 144 in 78ebcb6

$drawioHost = $drawioSourceParsed['scheme'] . '://' . $drawioSourceParsed['host'];

[thickconfusion]

I commented out my ALLOWED_IFRAME_SOURCES line entirely, with my DRAWIO=http://172.31.1.167:8080/?embed=1&proto=json&spin=1&configure=1&stealth=1. I cleared browser cache, and I still have the problem. I again verified that I can launch http://172.31.1.167:8080 and Draw.IO loads just fine.

[ssddanbrown]

Sure, I was just saying that we attempt to handle this so you shouldn't have to set the iframe sources, but we currently don't handle custom defined ports.

I've now fixed port handling via 897bb33, with testing to cover, which will be part of the next patch release so I'll therefore close this off.

Not sure why your custom ALLOWED_IFRAME_SOURCES additions did not work, since I could work around this on my dev instance via this method, but could be down to browser specifics or configuration changes not take place when expected.

If you still have issues after the next patch release feel free to still comment here for further investigation.