Additional options for api.access.deny() in actions to trigger code on the backend

Feedback
1

Right now the default behavior is that the access.deny methods redirects the user to the default app where devoplers have to handle the error states. This behavior is totally fine.

But it would be cool to have an option to have an additional paramater besides the one provided: success=false and error=message.

I think something of something like an “errorCode”.

Right now the only discriminator for handling error types in the tool is the error string itself.

In my case I have multiple reasons for denying access to the tool:

  • missing permissions (should be handled in one dedicated view)
  • email confirmation (should be handled in another dedicated view)
  • general error handling like “invalid state” (should be handled in default view)

As you can see, it would be much easier to pick a view if there was an additional discriminator beside the message itself.

2

Hey there!

Thank you Hendrik for creating this feedback card and providing all that context. Let’s see if it’s gonna get some traction with other community members!

1 Like
3

It might also be worth noting this would match the api.access.deny() method of the credential-exchange api object.

4

It would be very helpful to be able to set the http-code of the response. Right now deny() returns a 500 which is inappropriate for most use-cases.

3 Likes
5

Hey @bruno.crisafulli thanks a bunch for following up with the feedback :pray: Our team monitors these closely for community engagement.