-
-
Notifications
You must be signed in to change notification settings - Fork 382
Description
Is your feature request related to a problem? Please describe.
With the new sandboxed pre- and post-script implementation, sharing data between the Altair initiator and Altair itself has become nearly impossible. In this comment, I described my use case requiring a bearer token to be shared from my web application to Altair. The only viable workaround is reverting to the previous implementation via persistedSettings: { "beta.disable.newScript": true }.
I understand the security concerns behind the new pre/post script implementation but legitimate use cases exist where pre/post scripts need controlled access to specific host application data.
Describe the solution you'd like
I don’t have a strong preference for the exact implementation, but my use case stores the bearer token in localStorage, which could be a suitable solution because:
- It enables fine-grained control over shared data
localStorageis the standard for in-browser data storage- Altair already leverages
localStorageto share its own state via the new worker-based implementation
Proposed approach: Add a script.allowedLocalStorage configuration option (e.g., ["authToken", "userSettings"]) to explicitly whitelist keys. This would meet all requirements without compromising security. 🤷🏼♂️
Describe alternatives you've considered
Alternatives are already described here. Sadly, these alternatives are insufficient:
- disable
preserveState-> the least ideal solution because many core Altair features relies on state preservation - API endpoint -> requires backend integration, might be outside web app developer’s control
- using cookies -> Security risk (cookies leak to external APIs, designed for network requests, not browser storage)
- relying on internal API/behavior -> discouraged, subject to breaking changes