Hi,
It seems as though the "x-retool-forward-for" header is not getting passed to our backend when we use a GRPC resource query. This makes it impossible for us to tell the source of the originating retool usage. We require this for securing our admin portal, and it has become quite difficult for us to build and scale our solution without it.
@Tess Could you also consider this please?
Hey @travis_foyer - It's probably not something we'll be able to get to in the near future with other development priorities the team's working on. As a workaround, you could try getting the client IP by parsing a dummy REST request's metadata on page load, and then pass that through whichever query's metadata.
The below example just hits the same Retool instance I'm using's health check endpoint (so should always be available). It's not ideal to add that reference in the metadata for every query, but looks like user attributes are respected at the resource level. You'd just need to work out updating the attribute for the user on page load through the Retool API and what not.
Thanks @jmann for the workaround.
This could probably work for us, but its certainly not ideal. We have more than a few dozen (and growing) gRPC calls that would need to reference localStorage and/or userAttributes for this captured ipAddress to inject into the metadata.
Also the question is when do we refresh the captured IP? every x mins?
Seems like an quick one for retool to add automatically to gRPC calls, similar to whats already being done with REST Api calls?
Yeah know it's definitely not ideal. But dug into the existing header implementation that has only ever been a thing for REST queries, and generalizing it into different resource types is a bit more involved than a quick patch.
If you want to try the user attribute route, the extra build is two queries per app (dummy to get the IP, which triggers the set user attribute Retool API call). I confirmed the resource-level metadata config works for that, so there's nothing needed for each grpc query at least.
And if a user's IP changing within a session is important for the use case, you can set the query to run however often you'd like in the IP query's advanced settings.
