Customizing Interface Calls Interception for Custom 401 and 400 Responses with Redirect to /login Page

[monlor]

I hope this message finds you well. I'm reaching out to inquire about a specific functionality within Wasp-lang that I'm looking to implement in my project.

I'm interested in customizing the interception of interface calls to facilitate the following functionalities:

Custom 401 and 400 Responses Format: I aim to customize the response format for HTTP status codes 401 and 400 when an interface call encounters these errors. This customization would allow for a more tailored response to these specific error scenarios.

Redirect to /login Page on 401: Upon encountering a 401 Unauthorized status code, I would like the application to redirect the user to the /login page. This functionality is crucial for enhancing user experience and ensuring seamless navigation within the application.

I would greatly appreciate any guidance, suggestions, or resources you could provide regarding how to achieve these functionalities within Wasp-lang. Additionally, if there are any existing features, configurations, or plugins that facilitate this, please do point me in the right direction.

Thank you very much for your time and assistance.

[Martinsos]

@monlor I believe you are looking for https://wasp-lang.dev/docs/auth/overview#onauthfailedredirectto-string- ! So in main.wasp file, you would have something like:

app crudTesting {
  // ...
  auth: {
    ...
    onAuthFailedRedirectTo: "/login",
  },
}

Does this solve your problem?

[monlor]

Thank you for your reply. I have configured onAuthFailedRedirectTo: ”/login“, but when 401 appears, it does not automatically jump to the /login page. So I hope to customize that when 401 appears, I will actively redirect /login, and I also need to uniformly process the format of the interface range, such as the 400 interface return {”status“: 400}

[Martinsos]

I am surprised by that, I would expect 401 to send you to /login in this case!
How do you test this -> do you try to access the page with unauthenticated user? What happens for you in that case then, if it doesn't take you to /login?

I didn't quite get the uniformly process part. What do you mean by "400 interface"?
So what we have is an HTTP API responding to requests, and it can respond with 200 if all ok, 400 if some general issue with request, 401 if unauthorized, ... .

[monlor]

When I log out, I always stay on this page, and an interface call getuser 401 appears. It doesn't automatically exit to the login page, so I hope I can manually log out.

[monlor]

Regarding intercepting the 400 request interface, what I want to express is that when there is a processing error in the program, the 400 interface will directly return the error stack to the user, which is not what we want to see. I want to intercept the 400 interface and make it return the error format I expect.