Wanted to share something that I struggled with some. I wanted to make a different table viewer, but this meant I needed to be able to hit the tables api to get all of its records. Here is a function that does just that. Two things you need to change:
Create a bot in your instance, and copy its basic auth code to the authorizationBasic variable.
Update the URL you want to pull data from inside the request object.
I just wrote a feature request that’s related to this. This approach you outlined here is an okay workaround, but there’s a few things that bother me.
The Tulip front-end already has access to the Table API and credentials. To get those credentials, the user might even have had to have used 2FA.
I don’t know if the credentials the UI uses are temporary or not (I hope so) but if they’re tied to the user’s login, then they are also tied to the client’s security policy e.g. maybe SAML2/LDAP, maybe requiring 2FA
You can’t really rotate bot credentials without having to go touch every widget, or, alternatively, make the credentials an input to the widget. Neither of those things are great.
Once you give the widget bot credentials, those credentials have access to every table, which just increases the vulnerability footprint
what I am suggesting instead is that we make the ability for custom widgets be a first-class citizen. Hand the widget a table reference, give it get() create() update() delete() methods associated with the specific tables passed into the reference, and have those methods automatically inject the same credentials the UI user is already using.
Along the same lines, step 2 would be pass in a reference to the App with a few methods like .complete() and .goToNamedStep(“something”).
Probably should discuss this in my feature request thread rather than here.