There is one API resource configured with custom authentication. The setup of both environments is the same except for the API urls.
The initial login works flawlessly. All queries succeed. Now when i switch to the staging environment by using the switch bottom left, i am asked to authenticate myself agains the staging resource API. Everything as expected until here. Once i finish the OAuth Flow and come back to the page where i've been previously, my resource queries run right away but all fail due to being unauthorized (HTTP 401).
This is a blocking issue for us since we have operation team members who need to switch environments. I tried delaying the resource queries if i find the OAuthFinished url parameter in the url, but no luck (Page load delay does not take retool variables).
The only workaround currently seems to be going in Edit mode (which endusers can not do), trying to run the query, hit re-auth and complete the OAuth flow. Then it works.
Just need to ask some clarifying questions to better understand the situation and hopefully help.
When you said " Once i finish the OAuth Flow and come back to the page where i've been previously" are you saying that you are switching back to the first environment, or are you coming back to the app editor of the second env which you had switched into and then authed into?
Are you switching back environments after the second auth in, to where the user first accessed and successfully authed into(first env)?
So for example, the user auths into dev env, switches to prod env and auths in to prod, THEN on switching back to dev env the queries run and fail with unauthorized (HTTP 401)?
And then to your second point, where the work around seems to be going to edit mode to re-auth again.
This should be the normal flow for app editing team members.
End users of an app should not be switching back and forth between environments (unless this is your use case) and thus should only have to auth in once in the env of the app they are using.
The purpose of having auth on resources is to make sure that users entering into the env confirm their identity and that they have permissions. I do not believe auth tokens for one environment will persist over changing to another env and then back again, as this could be exploited by malicious actors.
But if you give me more details on the use case flow I can see what other options there are for working with multiple auths for multiple environments for app editors/developers vs app users/consumers
thank you for reaching getting back so fast. Sure, let me try to clarify our workflow.
We have an operational team working with our retool apps as endusers. When developing features for our product or for our retool apps, we usually first deploy to our staging environments. This includes staging deployments in the backend, in the frontend of our product and also preparing the changes in retool.
Before releasing the changes to all of our users, we want to enable our operations team to thoroughly test and review the changes in order to verify everything works flawlessly and is operational. From my point of view it is very common to review features on staging before moving to production.
This introduces the requirement that our operational team needs to be able to switch environments (staging, production). But as of now, we have the issue that I described which prevents us from doing so.
I hope I was able to clarify the concern. I will also happily share a video of the issue with you privately if you could provide me with an email address.
Hope you had a good weekend! Ok I see, thank you for the explanation of the development flow that helps me understand the situation much better. It sounds like a correct and standard app development flow, so I would love to get you and the team unstuck on this.
I would definitely like to see a video of the behavior. You can DM me in the community forum, or if sending an email is easier I am at. jack .t@retool (no space, that is just to keep web crawlers from scraping my data).
Do the operation team members not have edit access to both environments? In my head, they should be able to switch between the two environments for testing, and I am going to double check that they should be re-prompted to auth into protected resources on switching envs, and then should not hit any errors.
If they do need to go into the app editor to re-auth on env switch, that should be a reasonable step to development that ensures maximum security, with end users of the app only using one env and authing to those resources once as needed.
But I am sure the video will help me understand how the dev flow can be best optimized, as your team should be able to develop and test without hitting unauthorized (HTTP 401) errors. Or be able to easily auth in when needed, to meet auth requirements.
Do the operation team members not have edit access to both environments? No, they are only allowed to view (endusers) and have no edit access. The operations team has no technical insights or IT knowledge, which is why we don't want them to go in edit mode as well.
Instead, we have implemented a select input in the navbar to show the current environment and to switch to the staging environment. For this, we are redirecting the user to the index app (dashboard) with query parameter index?_environment=staging. By doing so, retool switches the env to staging and will use the API with staging environment settings. Here's a screenshot showing the select input.
I will send you the video as well to your email address.
Looking forward to get this resolved together, thanks a lot!
@OliverSo Thank you so much for the video and explaining the situation!
That is very interesting that you have the ops team using the dropdown to switch environments via URL makes sure that they don't accidentally edit anything.
First question, is this a Query Library query? Those have been known to have some odd interactions at times so just want to rule that out.
Are you able to test only the staging env, to see if it works without switching?
If you are able to share a screenshot of how is the resource configured, maybe we can see if there are any red flags I can spot that could be causing this
One of the other support engineers suggested checking the token status on staging. We can see if the token is stale or missing.
They were also thinking that defined var might not be grabbing the token correctly. If we look over the resource configuration we can see if something odd might be happening, such as the query could be hitting the wrong endpoint
We are mostly using Resource Queries with a GraphQL API. In some cases we do use the query library (again as Resource Queries with a GraphQL API). But this issue also happens on apps where we don't use the query library.
Yes, staging env works completely fine and is set up just as production, but with another URL. We have a token request and token refresh workflow within the resources. When editing the resource we are also able to test the auth flow and the refresh flow after each other. When checking the auth status, it says we are authenticated (works on both envs). Unfortunately, i'm not able to share screenshots here as it would expose internal endpoints.
After successful auth or token refresh, all we do in the resource workflow is to define a variable AUTH_TOKEN and REFRESH_TOKEN with the output values of the respective steps. These again are used as header values of the resource, which are defined in the resource itself as default headers.
So basically the auth and refresh seem to work fine when either triggered manually in the resource settings (for both envs) or through edit mode of an app. The only thing that does not work is not being in edit mode and switching envs, as requests will try to execute before the token (or maybe the header variable) is properly set.
Would there be any possibility for someone to have a quick look at the issue together with me in an 30m call? I'd really appreciate this as we are really stuck here.
Unfortunately we are lot allowed to jump on private 1-on-1 calls BUT we do have twice weekly office hours where we can help live debug with me and a team of other support engineers!
I think that might be the best option to figure out if there is a workaround or any setup steps we could tweak, or if this is a full bug that we can document and have our engineers fix.
Hope to see you there and get some progress on resolving this
makes sure that they don't accidentally edit anything.
