Updates toolsocket to latest version in objectDefaultFiles and fixes … #986
Conversation
…toolsocket loading in object.js
| const pathParts = window.location.pathname.split('/'); | ||
| const sourcePathname = pathParts.includes('frames') ? pathParts.slice(0, pathParts.indexOf('frames')).join('/') : window.location.pathname; | ||
| url = window.location.origin + sourcePathname; |
There was a problem hiding this comment.
Just out of curiosity, what is the motivation for this change?
I did a quick test and (assuming I ran this correctly) it seems like the old code results in a url like:
https://toolboxedge.net:443/n/OBxTG9K1AY313tXA0Fgl/i/lZjQV2rqp26mnhM/s/CxVKP2NDVV7HRf2AmR9qZOuHlHxrPxXQQvDjsiFN
while the new code produces one like:
https://toolboxedge.net/n/OBxTG9K1AY313tXA0Fgl/i/lZjQV2rqp26mnhM/s/CxVKP2NDVV7HRf2AmR9qZOuHlHxrPxXQQvDjsiFN
Does the :443 in the old version cause issues with the cloud proxy?
There was a problem hiding this comment.
When connected to a cloud-proxy running locally, the old code produces a URL like http://10.0.0.237/n/1vfg7mfUcG2A5tPK1wzT/i/H5aCIOszh0U2iMgv/s/mYMKKwgpTLnlVAzlGaIO0nmvoBjIwRNaq2ISdyHi/objectDefaultFiles/toolsocket.js, but it should be http://10.0.0.237:8000/n/1vfg7mfUcG2A5tPK1wzT/i/H5aCIOszh0U2iMgv/s/mYMKKwgpTLnlVAzlGaIO0nmvoBjIwRNaq2ISdyHi/objectDefaultFiles/toolsocket.js
|
To clarify, fixes issues with toolsocket loading in object.js when behind a local cloud-proxy in development |
…toolsocket loading in object.js when behind cloud proxy