Add support for custom denied access reason

[jtinbergen]

✨ Summary

This PR introduces custom deny reasons for buildAbacPolicy policies. It does so by wrapping the condition call in a try/catch and using the thrown error message into a DeniedAccessResult. It will fall back to the default message when no message property is present on the error.

---

🛠️ Changes

• Added exception handling to the buildAbacPolicy function
• Extended unit tests to cover custom denial reasons

---

🔍 Why

This change is part of providing better error reasons for failing policies so failure is easier to understand. Currently it only says the condition evaluated to false

---

⚠️ Notes for Reviewers

• Please note that no existing test was changed and all existing and new test(s) are green.
• An extra test was added to verify the try/catch error handing with custom reasons for buildAbacPolicy.

---

✅ Testing

• ✅ All unit tests passing

[9Morello]

First of all, thanks for taking the time to make this PR, I appreciate it!
Could you elaborate a bit on your use case? Usually, you can indicate the reason for denying access by giving your policy a name. For example, if you have an ABAC policy called "Public documents have READ access for anyone accessing it", and that policy denies access, it should implicitly mean the document is not public.

Wrapping it in a try/catch blog may hide bugs on the underlying business logic as well.

[jtinbergen]

I am curious to understand why it would hide the defects in the underlying code since the error message is still associated with the deny reason. As to my use case: I have policies which are incremental-- first checking if resources are allowed before checking if the correct actions are set on the resources allowed and so on. Its harder splitting this incremental logic over multiple policies since each step needs the output from the previous one-- but for the end user and/or debugger its very valuable to know what the policy failed on exactly, not just that the policy with that name failed. In other words: its about providing a custom reason the policy failed instead of 'it returned false'

[9Morello]

@jtinbergen Sorry for not getting back to you sooner. I've just been busy at $dayjob and didn't have the time to put more thought on this PR. As to not block your use case, maybe you could consider vendoring the library, at least for the time being. If your toolchain supports TS directly, you only have to add a single file to your folder.

Again, sorry for the inconvenience.

[jtinbergen]

I have done so and modified the code to give custom reasons back instead of 'access denied' depending on where in the 'condition' it failed. Thanks. Op vr 27 jun 2025 om 17:09 schreef 9Morello ***@***.***>:

…

*9Morello* left a comment (9Morello/gatehouse-ts#2) <#2 (comment)> @jtinbergen <https://github.com/jtinbergen> Sorry for not getting back to you sooner. I've just been busy at $dayjob and didn't have the time to put more thought on this PR. As to not block your use case, maybe you could consider vendoring the library, at least for the time being. If your toolchain supports TS directly, you only have to add a single file to your folder. Again, sorry for the inconvenience. — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANP22GUZEDLVVZU32DQLID3FVNDDAVCNFSM6AAAAAB7F6UINGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMJTGQYDOMJSGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Met vriendelijke groet, Jaapjan Tinbergen