Draw.io name change to diagrams.net #1660

Closed
opened 2026-02-05 01:32:16 +03:00 by OVERLORD · 11 comments
Owner

Originally created by @TBK on GitHub (Apr 16, 2020).

Draw.io is transitioning to diagrams.net. They have published a blog post about it https://www.diagrams.net/blog/move-diagrams-net

Originally created by @TBK on GitHub (Apr 16, 2020). Draw.io is transitioning to diagrams.net. They have published a blog post about it https://www.diagrams.net/blog/move-diagrams-net
OVERLORD added the 📖 Docs Update label 2026-02-05 01:32:16 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Apr 25, 2020):

Thanks for advising @TBK. I did see this but from that blog post:

We are testing https://app.diagrams.net to check everything that works on the draw.io domain works there. Don’t switch away from www.draw.io just yet.

I'll keep this open as a reminder and then, maybe later this year, if there have been no issues, We can update the docs and code to refer to diagrams.net. Will not change the DRAWIO env options though as not really worth changing.

Reminder to myself to make this visible as an upgrade note, when it's implemented, since there could be enterprise environments that have whitelisted the draw.io domain.

@ssddanbrown commented on GitHub (Apr 25, 2020): Thanks for advising @TBK. I did see this but from that blog post: > We are testing https://app.diagrams.net to check everything that works on the draw.io domain works there. Don’t switch away from www.draw.io just yet. I'll keep this open as a reminder and then, maybe later this year, if there have been no issues, We can update the docs and code to refer to diagrams.net. Will not change the `DRAWIO` env options though as not really worth changing. Reminder to myself to make this visible as an upgrade note, when it's implemented, since there could be enterprise environments that have whitelisted the draw.io domain.
Author
Owner

@davidjgraph commented on GitHub (Jul 31, 2020):

@ssddanbrown We're not in any rush and we're not changing underlying names from drawio, either. Literally, nobody calls it diagrams.net.

The only thing to mention, if anyone is embedding draw.io directly from the hosted version, is that we would like to set the frame header to only allow embedding on embed.diagrams.net. This is a security improvement, that URL won't allow permissions to cloud storage and so removes a number of clickjacking attacks.

If it's just docs, don't worry about it, it'll be called draw.io more than diagrams.net for a long time...

@davidjgraph commented on GitHub (Jul 31, 2020): @ssddanbrown We're not in any rush and we're not changing underlying names from drawio, either. Literally, nobody calls it diagrams.net. The only thing to mention, if anyone is embedding draw.io directly from the hosted version, is that we would like to set the frame header to only allow embedding on embed.diagrams.net. This is a security improvement, that URL won't allow permissions to cloud storage and so removes a number of clickjacking attacks. If it's just docs, don't worry about it, it'll be called draw.io more than diagrams.net for a long time...
Author
Owner

@nutsflag commented on GitHub (Sep 28, 2020):

Hello @ssddanbrown,

You have to modify the url in form.blade.php.

A user has been impacted (Issue #2285)

@nutsflag commented on GitHub (Sep 28, 2020): Hello @ssddanbrown, You have to modify the url in form.blade.php. A user has been impacted (Issue #2285)
Author
Owner

@davidjgraph commented on GitHub (Sep 28, 2020):

We excluded "https://www.draw.io?embed=1*" from the redirect, going to https://www.draw.io/?embed=1&proto=json&spin=1 shouldn't give you a redirect.

But yes, anything www.draw.io needs to become embed.diagrams.net at some point. The security on embed.diagrams.net is better than on the old domain.

@davidjgraph commented on GitHub (Sep 28, 2020): We excluded "https://www.draw.io?embed=1*" from the redirect, going to https://www.draw.io/?embed=1&proto=json&spin=1 shouldn't give you a redirect. But yes, anything www.draw.io needs to become embed.diagrams.net at some point. The security on embed.diagrams.net is better than on the old domain.
Author
Owner

@nutsflag commented on GitHub (Sep 28, 2020):

Hello,
There is a redirection which is done.
First :
Request URL: https://www.draw.io/?embed=1&proto=json&spin=1
Request Method: GET
Status Code: 301
Remote Address: 104.22.56.156:443
Referrer Policy: strict-origin-when-cross-origin

Second :
Request URL: https://app.diagrams.net/?embed=1&proto=json&spin=1
Request Method: GET
Status Code: 200 (from ServiceWorker)
Referrer Policy: strict-origin-when-cross-origin

@nutsflag commented on GitHub (Sep 28, 2020): Hello, There is a redirection which is done. First : Request URL: https://www.draw.io/?embed=1&proto=json&spin=1 Request Method: GET Status Code: 301 Remote Address: 104.22.56.156:443 Referrer Policy: strict-origin-when-cross-origin Second : Request URL: https://app.diagrams.net/?embed=1&proto=json&spin=1 Request Method: GET Status Code: 200 (from ServiceWorker) Referrer Policy: strict-origin-when-cross-origin
Author
Owner

@davidjgraph commented on GitHub (Sep 28, 2020):

Try clearing the 301 from the browser cache, like https://stackoverflow.com/questions/16154672/how-long-does-chrome-remember-a-301-redirect

@davidjgraph commented on GitHub (Sep 28, 2020): Try clearing the 301 from the browser cache, like https://stackoverflow.com/questions/16154672/how-long-does-chrome-remember-a-301-redirect
Author
Owner

@nutsflag commented on GitHub (Sep 28, 2020):

Yes, but one user has been impacted as mentioned above. Changing the url unlocked the situation. Knowing that Draw has notified the domain change, it would be good to apply it for the next release.

@nutsflag commented on GitHub (Sep 28, 2020): Yes, but one user has been impacted as mentioned above. Changing the url unlocked the situation. Knowing that Draw has notified the domain change, it would be good to apply it for the next release.
Author
Owner

@Kabe0 commented on GitHub (Sep 28, 2020):

Clearing the cache has not worked for me on this issue. The redirect itself is not the problem, the issue is the app.diagrams.net response includes the following which locks the iframe from being able to render the content. They are no longer allowing people to use the app.diagrams.net for embedding.

x-frame-options: SAMEORIGIN

@Kabe0 commented on GitHub (Sep 28, 2020): Clearing the cache has not worked for me on this issue. The redirect itself is not the problem, the issue is the app.diagrams.net response includes the following which locks the iframe from being able to render the content. They are no longer allowing people to use the app.diagrams.net for embedding. **x-frame-options: SAMEORIGIN**
Author
Owner

@davidjgraph commented on GitHub (Sep 28, 2020):

Could someone grep this codebase for "app.diagrams.net" ?

@davidjgraph commented on GitHub (Sep 28, 2020): Could someone grep this codebase for "app.diagrams.net" ?
Author
Owner

@ssddanbrown commented on GitHub (Sep 28, 2020):

Thanks @davidjgraph for officially advising here and thanks for the info on embed.diagrams.net from before, I had missed that message. app.diagrams.net not already in the codebase (In a release)

My findings:


https://www.draw.io/?embed=1&proto=json&spin=1 Does seem to provide a redirect:

➜  ~ curl -s -D - -o /dev/null 'https://www.draw.io/?embed=1&proto=json&spin=1'
HTTP/2 301 
date: Mon, 28 Sep 2020 19:32:01 GMT
cache-control: max-age=3600
expires: Mon, 28 Sep 2020 20:32:01 GMT
location: https://app.diagrams.net/?embed=1&proto=json&spin=1
cf-request-id: 0577cc6af30000e5fc9f1f3200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
server: cloudflare
cf-ray: 5d9fe357e9aae5fc-LHR

The resulting location does not seem to set x-frame-options:

➜  ~ curl -s -D - -o /dev/null 'https://app.diagrams.net/?embed=1&proto=json&spin=1'      
HTTP/2 200 
date: Mon, 28 Sep 2020 19:34:00 GMT
content-type: text/html
set-cookie: __cfduid=df0adc1c9780109e24d71506d3307551f1601321640; expires=Wed, 28-Oct-20 19:34:00 GMT; path=/; domain=.diagrams.net; HttpOnly; SameSite=Lax; Secure
access-control-allow-origin: *
referrer-policy: strict-origin
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
expires: Mon, 28 Sep 2020 19:44:00 GMT
cache-control: public, max-age=600
x-cloud-trace-context: 394991155463bd6fa2abd23270c74b9e
cf-cache-status: DYNAMIC
cf-request-id: 0577ce39080000bb94a6a06200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
strict-transport-security: max-age=31536000; includeSubDomains
server: cloudflare
cf-ray: 5d9fe63b48f2bb94-LHR

Of course those are my results via CURL; Region, time and request headers may have an affect. That said, In my browser (Including on the BookStack demo site) the requests behave the same (Get redirected to the app.diagrams.net instance with a notification).

In my testing everything still works though, I don't see any x-frame-options along the way.

Either way, I'll look to get include this in the next patch release, Thanks all for having a dig into this

@ssddanbrown commented on GitHub (Sep 28, 2020): Thanks @davidjgraph for officially advising here and thanks for the info on embed.diagrams.net from before, I had missed that message. `app.diagrams.net` not already in the codebase (In a release) My findings: --- https://www.draw.io/?embed=1&proto=json&spin=1 Does seem to provide a redirect: ``` ➜ ~ curl -s -D - -o /dev/null 'https://www.draw.io/?embed=1&proto=json&spin=1' HTTP/2 301 date: Mon, 28 Sep 2020 19:32:01 GMT cache-control: max-age=3600 expires: Mon, 28 Sep 2020 20:32:01 GMT location: https://app.diagrams.net/?embed=1&proto=json&spin=1 cf-request-id: 0577cc6af30000e5fc9f1f3200000001 expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" strict-transport-security: max-age=31536000; includeSubDomains x-content-type-options: nosniff server: cloudflare cf-ray: 5d9fe357e9aae5fc-LHR ``` --- The resulting location **does not** seem to set `x-frame-options`: ``` ➜ ~ curl -s -D - -o /dev/null 'https://app.diagrams.net/?embed=1&proto=json&spin=1' HTTP/2 200 date: Mon, 28 Sep 2020 19:34:00 GMT content-type: text/html set-cookie: __cfduid=df0adc1c9780109e24d71506d3307551f1601321640; expires=Wed, 28-Oct-20 19:34:00 GMT; path=/; domain=.diagrams.net; HttpOnly; SameSite=Lax; Secure access-control-allow-origin: * referrer-policy: strict-origin x-content-type-options: nosniff x-xss-protection: 1; mode=block expires: Mon, 28 Sep 2020 19:44:00 GMT cache-control: public, max-age=600 x-cloud-trace-context: 394991155463bd6fa2abd23270c74b9e cf-cache-status: DYNAMIC cf-request-id: 0577ce39080000bb94a6a06200000001 expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" strict-transport-security: max-age=31536000; includeSubDomains server: cloudflare cf-ray: 5d9fe63b48f2bb94-LHR ``` --- Of course those are my results via CURL; Region, time and request headers may have an affect. That said, In my browser (Including on the BookStack demo site) the requests behave the same (Get redirected to the app.diagrams.net instance with a notification). In my testing everything still works though, I don't see any `x-frame-options` along the way. Either way, I'll look to get include this in the next patch release, Thanks all for having a dig into this
Author
Owner

@ssddanbrown commented on GitHub (Oct 1, 2020):

This has now been changed in BookStack v0.30.2

@ssddanbrown commented on GitHub (Oct 1, 2020): This has now been changed in [BookStack v0.30.2](https://github.com/BookStackApp/BookStack/releases/tag/v0.30.2)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#1660