The documentation lists the following reason
If JavaScript ran directly on your page, other people in your org could XSS you. To prevent that, we execute all JavaScript in a separate iframe, on a different domain.
But if someone is part of your Retool account doesn't that mean that you already trust them?
If only certain people are allowed to modify the JS code, won't this be enough?
Hi @vangelov
assuming there aren't security concerns, what is the additional benefits running js within the main app?
You would have access to the DOM API for the actual app.
I.e. you can add event listeners to the document, call any APIs you want and generally be able to implement anything that's possible in a standard web app and is not yet in Retool.
For example: scrolling the window or showing an alert before closing the app.
Although I understand that Retool would enforce strong sandboxing with the cloud edition, I find it very frustrating not to be able to basically 'do what we want' with the self-hosted edition. We are in an environment we control, why couldn't we load any lib we need to ?
I agree. This causes a CORS issue where a JS query has a null origin in my self-hosted instance. Is there any workaround for this? (running JS queries in the browser-side to avoid this CORS issue)
We are tracking this as a feature request in our backlog, but I don't have an update at the moment.
@pablo.estrada can you share more about what you're looking to do in Retool?
Yes, due to my org's authentication setup, Retool backend queries will not delegate user's principal from the Retool backend.
However, it seems like it would be possible to delegate the user's principal through frontend queries (using CORS), so I was hoping I could execute a purely frontend REST query in Retool. It seems like that is not possible due to the sandboxed JS queries.