RBAC middleware support #2144

goginenibhavani2000 · 2025-08-11T20:47:14Z

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 · 2025-08-13T06:08:59Z

examples/rbac/config.json

+{
+    "roles": {
+      "admin": ["*"],
+      "editor": ["/posts/*", "/dashboard"],
+      "user": ["/profile", "/home", "/sayhello*","/greet"]
+    }
+  } 


Roles should be defined at route level, not the other way around. That would allow clarity on who all can access a given route.

akshat-kumar-singhal · 2025-08-13T06:11:30Z

pkg/gofr/rbac/match.go

+	"strings"
+)
+
+func isPathAllowed(role, route string, config *Config) bool {


We shouldn't reinvent the path matching, utilise existing packages.

akshat-kumar-singhal · 2025-08-13T06:12:40Z

pkg/gofr/rbac/helper.go

+	return expRole == role
+}
+
+func IsAdmin(ctx *gofr.Context) bool {


Roles should not be hardcoded into the framework. They are just strings, should not have a literal meaning defined in the framework.

akshat-kumar-singhal · 2025-08-13T06:13:11Z

pkg/gofr/rbac/helper.go

+	return HasRole(ctx, "admin")
+}
+
+func GetUserRole(ctx *gofr.Context) string {


Errors should not be silently ignored

it returns a bool, so have ignored it

akshat-kumar-singhal · 2025-08-13T06:14:51Z

pkg/gofr/rbac/helper_test.go

+			gofrCtx := &gofr.Context{Context: baseCtx}
+
+			got := HasRole(gofrCtx, tt.checkRole)
+			if got != tt.expectedRes {


Consider using assert.Equal/Equalf to make it more concise

akshat-kumar-singhal · 2025-08-13T06:21:08Z

examples/rbac/main.go

+}
+
+func extractor(req *http.Request, _ ...any) (string, error) {
+	return req.Header.Get("X-USER-ROLE"), nil


User role passed in the header cannot be trusted as is. While this may have been added as an example only, it'd be better to have a proper example.

akshat-kumar-singhal · 2025-08-13T06:23:39Z

examples/rbac/main.go

+	app.UseMiddleware(rbac.Middleware(rbacConfigs))
+
+	app.GET("/sayhello/123", handler)
+	app.GET("/greet", rbac.RequireRole("user1", handler))


This is defeating the purpose of middleware if every route needs to add this RequireRole

requireRole is not needed for every route, can be directly used as app.GET("/sayhello/123", handler)

akshat-kumar-singhal · 2025-08-13T18:56:41Z

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 · 2025-08-20T11:25:01Z

@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 · 2025-08-20T11:28:36Z

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 · 2025-08-20T11:32:54Z

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 · 2025-08-20T11:47:10Z

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 · 2025-09-03T06:27:13Z

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

goginenibhavani2000 added 6 commits July 17, 2025 19:41

Implemented RBAC middleware support with example

9170451

Add route specific override and fix userRole read from context

a123a03

remove unneccessary changes

e59fd18

Merge branch 'development' into RBAC-middleware-support

993dd2e

Added unit tests to rbac package

23073f7

fix linters

0a0334f

goginenibhavani2000 mentioned this pull request Aug 11, 2025

RBAC(Role-Based Access Control) Support #2000

Open

6 tasks

coolwednesday requested changes Aug 12, 2025

View reviewed changes

akshat-kumar-singhal suggested changes Aug 13, 2025

View reviewed changes

goginenibhavani2000 added 2 commits August 13, 2025 11:21

Merge branch 'development' into RBAC-middleware-support

2cb75bf

add go.od to separate out RBAC module

21b6309

coolwednesday added the gofr-soc label Aug 17, 2025

Umang01-hash and others added 3 commits August 20, 2025 17:22

Merge branch 'development' into RBAC-middleware-support

c57a2e1

Merge branch 'development' into RBAC-middleware-support

0f9226d

defining roles at route level and using assert.equal in test files

03b7ab9

RBAC middleware support #2144

Are you sure you want to change the base?

RBAC middleware support #2144

Uh oh!

Conversation

goginenibhavani2000 commented Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coolwednesday left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akshat-kumar-singhal commented Aug 13, 2025

Uh oh!

Umang01-hash commented Aug 20, 2025

Uh oh!

Umang01-hash commented Aug 20, 2025

Uh oh!

akshat-kumar-singhal commented Aug 20, 2025 via email

Uh oh!

Umang01-hash commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Umang01-hash commented Sep 3, 2025

Uh oh!

Uh oh!

goginenibhavani2000 commented Aug 11, 2025 •

edited

Loading

Umang01-hash commented Aug 20, 2025 •

edited

Loading