As far as I know this became broken in the last couple of days. I am normally working in the IDE and am therefore authenticated but a colleague is normally using the public URL to access the app and he just stumbled into this problem this afternoon and this is a very common action so we are pretty sure we would have noticed if it was broken yesterday or earlier.
The problem is this:
- User is accessing app using public URL.
- User action calls a Resource Query where the resource is Retool Workflow.
- A request to login is triggered.
If the user is already logged in no problem. Basically public apps can't call workflows at the moment.
So far we are pretty sure more than one Workflow is doing the same thing.
I did "rotate the API key" and redeploy on one workflow but that did not fix anything.
EXPERIMENT:
I converted it from a workflow query to a rest API query. And finally got that working inside the IDE. Now to test from a public session....
That fixes the problem. In other words:
If the Resource is a Retool Workflow unauthenticated browsers throw the logon page.
If the Resource is a REST API query unauthenticated browsers call the workflow and get back a result.
This is BAD and/or extraordinarily inconvenient and definitely this is new behavior.
In the chrome debugger I see this call:
Followed by Failed to load resource: the server responded with a status of 401 ()
Which make sense because this is a public user who is not logged in. The question is how is this suppose to work and why does it work sometimes and not others.
My colleague just reports "success" in the last hour. However it still fails for me in an incognito mode browser. And then it failed again for him later.