RBAC middleware support

[goginenibhavani2000]

Description:

• Added a declarative RBAC middleware with JSON‑defined roles, flexible role extraction, pattern matching, and helper functions enables consistent, reusable, and easy‑to‑maintain authorization across routes.
• Addresses RBAC(Role-Based Access Control) Support #2000
• GoFr has no native RBAC, forcing manual, repetitive route‑level authorization that risks inconsistency and increases maintenance. Expected Benefits include centralized, configurable, and reusable access control that’s easier to maintain, more flexible, and improves security.

Breaking Changes (if applicable):

• None

Additional Information:

• No relevant dependencies effected or external libraries used.

Checklist:

• I have formatted my code using goimport and golangci-lint.
• All new code is covered by unit tests.
• This PR does not decrease the overall code coverage.
• I have reviewed the code comments and documentation for clarity.

[coolwednesday]

We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework.

[akshat-kumar-singhal]

We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework.

@coolwednesday What's the advantage of having RBAC in another module, unless we move the auth middlewares into a separate module as well?

[Umang01-hash]

@goginenibhavani2000 please go ahead and resolve the review comments given by the reviewer. While we decide whether to keep it inside or outside like a separate module i think we can focus on completing the implementation, testing, documentation etc. Please let us know if you know any more help.

[Umang01-hash]

We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework.

@coolwednesday What's the advantage of having RBAC in another module, unless we move the auth middlewares into a separate module as well?

@akshat-kumar-singhal We see RBAC as a layer beneath Auth—more specialized and not universally required. Auth is core to GoFr and widely used, which is why its middlewares are bundled. RBAC, on the other hand, is optional and domain-specific, so we’re keeping it modular to avoid unnecessary coupling and binary weight.

[akshat-kumar-singhal]

Won’t it be taken care of by the dead code elimination done during build? I agree that RBAC shouldn’t be a default, but an easy to include module/package. What we could consider is having the interface for RBAC within gofr and the external module implementing that interface.

…

On Wed, 20 Aug 2025 at 16:58, Umang Mundhra ***@***.***> wrote: *Umang01-hash* left a comment (gofr-dev/gofr#2144) <#2144 (comment)> We would like to keep RBAC as a separate module. Hence add go.mod in it. So that it does not get added in the binary of the gofr framework. @coolwednesday <https://github.com/coolwednesday> What's the advantage of having RBAC in another module, unless we move the auth middlewares into a separate module as well? @akshat-kumar-singhal <https://github.com/akshat-kumar-singhal> We see RBAC as a layer beneath Auth—more specialized and not universally required. Auth is core to GoFr and widely used, which is why its middlewares are bundled. RBAC, on the other hand, is optional and domain-specific, so we’re keeping it modular to avoid unnecessary coupling and binary weight. — Reply to this email directly, view it on GitHub <#2144 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APUGM5WLZAMQTTVY4YHXRRD3ORLXVAVCNFSM6AAAAACDUPRBZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMBVG44DMNJTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Umang01-hash]

taken care of by the dead code elimination done during build? I agree that RBAC shouldn’t be a default, but an easy to include module/package. What we could consider is having the interface for RBAC

Yes that makes sense. WE can have the interface in GoFr and implementation outside.

[Umang01-hash]

@goginenibhavani2000 Are you still working on the issue. Please let us know in case you need any further help for the same.

[goginenibhavani2000]

@goginenibhavani2000 Are you still working on the issue. Please let us know in case you need any further help for the same.

Yes, i have completed the suggested changes except the change in having interface. Would like to confirm if the RBAC interface is like below

type RBAC interface {
RoleExtractor(r *http.Request, args ...any) (string, error)
IsPathAllowed(role string, path string) bool
}

[coolwednesday]

@goginenibhavani2000, So Sorry for the delay. I will be prioritising this issue review for the next week's release. Let me know if you are interested to tale this further if not, I myself will pick up this issue.

[goginenibhavani2000]

@coolwednesday I’d be happy to take this further and help with the changes. Let me know if there's anything specific you'd like me to focus on.

LGTM.

[Umang01-hash]

• In all the examples added, if the handlers are not using the ctx so we can keep the signature like :

func handlerName(_ *gofr.Context){}

• Files like adapter.go, jwt_extractor.go have very less coverage. Can we please try and improve it?

[aryanmehrotra]

code needs to be simplified, once the structural fixes are done code needs to be reviewed again.