[Bug][Feature] Custom authentication: refresh trigger

Feature Requests
1

Hi!

This is a bug report and a feature request. Decided to combine them as they are related. I have a cookie-based custom auth flow that goes like this:

  1. Auth workflow
    Logs in.
    Sets cookies used for auth. (Set-cookie from API).

  2. Refresh auth workflow
    POST /refresh
    refreshes the cookies (Set-cookie from API)

  3. Login trigger
    Validates that the user is signed in.

I'm currently developing locally using the on-premise docker container with a local backend API.

The problem I'm having is this:
All requests work fine, except for when there is a logical error. For instance, when I create a user that already exists I get an error: Conflict (409), however, any 4xx errors triggers the refresh auth flow and attempts again.

Feature request: The Conflict (409) is an error that should not be retried, it's a non-retryable error. There are many such examples. I understand the design to retry every non-2xx status code, however, there should be ways to circumvent this by specifying allowed non-2xx statuses for the 'Refresh auth workflow', or only specifying retryable non-2xx status (such as Unauthorized/Forbidden).

Bug report: Unfortunately, my case also includes an unexpected behavior:

Expected behavior:

  1. 409 Conflict - as mentioned above
  2. Refresh Auth workflow - the refresh auth is triggered. Sets new cookies used in (3)
  3. 409 Conflict - same error should happen again
    In (3) when the request is retried, the same error should occur. And Conflict (409) is shown in the retool app.

Actual behavior:

  1. 409 Conflict
  2. Refresh Auth workflow - Sets new cookies.
  3. 401 Unauthorized - Uses old cookies. But old cookies were invalidated in 2.
    ...(delayed) 4. Auth trigger - OK (200) - This request uses the new cookies. Request is authenticated.

In (3) Unauthorized is returned to the retool app. Which only happened because it did not use the new set-cookies received in (2). Some time later the auth trigger (4) runs with the new set-cookies instead.

Not sure if it's because of the development environment (with low latency), but this causes a lot of problems. I think the feature request could help solve these kinds of issues, but the core problem (of not updating the cookies consistently before re-triggering the request) should receive most of the attention.

Has anyone experienced this issue as well?

Best,
André

2

Hi @andreebie! Thanks for posting such detailed descriptions of both of your issues :slightly_smiling_face:

I've alerted the dev team of both the feature request and bug report and can let you know here when they've been addressed!

In the meantime, is the bug blocking for you? And if so - is there a case, in particular, where it is?

3

Hi @Kabirdas,

Great, please let me know! It's not blocking, but it is causing the retool apps to appear clunky. They often appear to lose access (but regain it on manual refresh) and some requests fail when they shouldn't.

I'll use a little workaround to rely less or not at all on the refresh auth workflow (by triggering the refresh periodically in the app instead) if I notice it becomes a bigger problem down the road.

Best,
André