Is there a way to access private models within the Visual Editor using webauth?

Technical Questions
1

I have a special case where I have CMS data models that have a preview URL.

I want to be able to display data from references to other private models on the preview URL. For public references, I would just resolve the reference client-side (e.g., with useEffect in React) and feed the data to my preview. But private references need a private API key to resolve, and I don’t want to include the private key in my JS bundle.

Also worth noting, the preview URL is only ever used within the Visual Editor for previewing/editing purposes, never for public consumption.

Is there some way to feed data into that preview URL from private models using Builder.io’s own webauth state? As in, is there a way to use your logged-in status within the Visual Editor to bypass the need for a private API key? If possible, it would be a major boon, because otherwise I need to either expose the private API key in my JS bundle or proxy the content API w/ the private key stored on the server, then create an authentication scheme to restrict access to either. But if I can just piggyback on top of Builder.io’s own auth just for accessing private content while within Visual Editor, that would save me a huge hassle.

@steve seemed to indicate that this was possible in a convo I had with him, but he didn’t elaborate and I may have misunderstood him. He’s busy, so at his suggestion, I’m opening up the convo to the forum. @TimG, any ideas?

This is a pretty advanced use case, I’m not sure it’s even technically possible.

I notice that the Firebase auth token gets stored in the browser using IndexedDB, and I’m assuming there’s some way to access private content with this. I don’t see how I can access that token from within the Visual Editor’s iframe, however. The browser considers the token and my JS running inside of the iframe as being on different domains, blocking access between the two. I don’t see anything inside of local storage or session storage that could be accessed cross-domain that would help.

2

Btw, I did think of the workaround of passing the private API key to the preview URL in the query params using a dynamic preview URL, but I think it’s a pretty big security risk. As soon as a user copies that preview URL containing the private key and sends it to a colleague outside of their org in an email, game over.

3

Hey @ersin this was going to be my work around recommendation for now, having some logic in the preview URL with a queryParam or something. As to your security concern, of course anytime you share a private key there is potential for security issue, if it is that significant of a concern for a private model I would recommend restricting access to those models only to certain roles that also have access to the private API key already if that is possible.

Anytime you grant anyone a admin or dev level of access in Builder of course there is potential for abuse (you can write code to your app), so it also just comes down to internal governance as well.

I think there is definitely a potential use case here, though like you said it is pretty advanced and rare…I would recommend submitting a feature request to ideas.builder.io to have it accurate prioritized by our product team.

Hope this helps!

1 Like