Http return code, login test and Custom Auth

Queries and Resources
1

Hi,

So when setting up the Login Test Url while using Custom Auth the http status return code which triggers the refresh flow should be configurable and not "anything" other than a 2xx.

Thanks,
Serge

3

Hi @ssozonoff,

Thanks for this feedback! I've put in a feature request for this in our backlog. I'll follow up here when it gets prioritized

4

Hi @ssozonoff I heard back from our team internally, and we were hoping you could share more context on your request. How would you like to configure the login test url (what codes would you like to check for)? What API/auth are you using?

From a spec point of view, a non 200 response code should not be used in the auth verification. Here is a summary for a few common 2xx codes.

  1. 200 OK:

• The standard and most commonly used response indicating that the request was successfully processed.

• Example: A token is valid, and the user is authenticated.

  1. 202 Accepted:

• Indicates that the request has been accepted for processing but the processing is not yet complete.

• Example: If verifying the token requires asynchronous operations or a delayed response (e.g., delegating to another service).

  1. 204 No Content:

• Indicates that the request was successful but there is no content to return in the body.

• Example: The token is valid, and no additional response data is necessary.

  1. 201 Created:

• Usually used when a new resource is created, but it might be applied in edge cases, such as creating a new session after authentication.

• Example: A new session token is issued after validation.

Thanks! I will share any additional context with our team for further consideration

5

Hi Tess,

So the easiest example to illustrate the type of issue with the current approach is that if the backend is behind a proxy or load balancer then it may return a 502,503,504 if the backend is unavailable for some reason.
This should in my opinion not trigger a re-auth. So while I agree that 2xx codes should definitely not trigger a re-auth I thinkthe best solution would be to let the developer decide what makes sense for his/her use case. Maybe start with some good defaults that work for most an option to further customise it.

Thanks,
Serge