The rules engine is a very nice feature to use, but in some cases it falls short.
For example, I might have an API that I want to secure, where resource creation and management is limited to authorized users, and reading is public:
GET /api/items -> public GET /api/items/* -> public POST /api/items -> private PUT /api/items -> private
The current rules options don't let me manage this, because the path is the same for many operations.
Instead, if I were able to filter by verb, I could easily setup a rule to forward to auth for all POST or PUT requests.
Originally created by @cascer1 on GitHub (Sep 4, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1408
The rules engine is a very nice feature to use, but in some cases it falls short.
For example, I might have an API that I want to secure, where resource creation and management is limited to authorized users, and reading is public:
`GET /api/items` -> public
`GET /api/items/*` -> public
`POST /api/items` -> private
`PUT /api/items` -> private
The current rules options don't let me manage this, because the path is the same for many operations.
Instead, if I were able to filter by verb, I could easily setup a rule to forward to auth for all POST or PUT requests.
@oschwartz10612 I've implemented HTTP method filtering for resource rules in #2131.
The implementation adds an optional method field to resource rules that allows filtering by HTTP verbs (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS). Rules without a method specified will continue to match all HTTP methods, so existing configurations remain fully compatible.
This should address the use case you described - you can now create separate rules for GET requests (public access) and POST/PUT requests (authenticated access) on the same path.
The changes include updates to both the database schema and UI, along with support for YAML-based blueprint configurations.
Let me know if you have any questions or feedback on the implementation.
<!-- gh-comment-id:3678654649 -->
@djcrafts commented on GitHub (Dec 21, 2025):
@oschwartz10612 I've implemented HTTP method filtering for resource rules in #2131.
The implementation adds an optional `method` field to resource rules that allows filtering by HTTP verbs (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS). Rules without a method specified will continue to match all HTTP methods, so existing configurations remain fully compatible.
This should address the use case you described - you can now create separate rules for GET requests (public access) and POST/PUT requests (authenticated access) on the same path.
The changes include updates to both the database schema and UI, along with support for YAML-based blueprint configurations.
Let me know if you have any questions or feedback on the implementation.
@djcrafts would this feature also be something you could add by any chance? https://github.com/orgs/fosrl/discussions/2109
(i made it a feat. request discussion because it is not really an 'issue', more of a (very welcome) addition to the rules.
and i see a use case in this situation as well, for example, to set "method get AND ip from country x", so am wondering if you think this is something doable for your commit ?
<!-- gh-comment-id:3678667212 -->
@thutex commented on GitHub (Dec 21, 2025):
@djcrafts would this feature also be something you could add by any chance? https://github.com/orgs/fosrl/discussions/2109
(i made it a feat. request discussion because it is not really an 'issue', more of a (very welcome) addition to the rules.
and i see a use case in this situation as well, for example, to set "method get AND ip from country x", so am wondering if you think this is something doable for your commit ?
@thutex Thanks for pointing this out! I’ve extended #2131 to support AND conditions, so you can now combine method with multiple predicates in a single rule (e.g., PATH + COUNTRY + method=GET), and existing single-condition rules still work. I also fixed the analytics chart typing issue I introduced—Recharts’ legend/tooltip expect a payload-props render function, so TypeScript complained; forwarding the payload props resolved it. All changes are pushed
<!-- gh-comment-id:3678695663 -->
@djcrafts commented on GitHub (Dec 21, 2025):
@thutex Thanks for pointing this out! I’ve extended #2131 to support AND conditions, so you can now combine method with multiple predicates in a single rule (e.g., PATH + COUNTRY + method=GET), and existing single-condition rules still work. I also fixed the analytics chart typing issue I introduced—Recharts’ legend/tooltip expect a payload-props render function, so TypeScript complained; forwarding the payload props resolved it. All changes are pushed
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @cascer1 on GitHub (Sep 4, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1408
The rules engine is a very nice feature to use, but in some cases it falls short.
For example, I might have an API that I want to secure, where resource creation and management is limited to authorized users, and reading is public:
GET /api/items-> publicGET /api/items/*-> publicPOST /api/items-> privatePUT /api/items-> privateThe current rules options don't let me manage this, because the path is the same for many operations.
Instead, if I were able to filter by verb, I could easily setup a rule to forward to auth for all POST or PUT requests.
@oschwartz10612 commented on GitHub (Sep 4, 2025):
Good point I think this is something we should do!
@djcrafts commented on GitHub (Dec 21, 2025):
@oschwartz10612 I've implemented HTTP method filtering for resource rules in #2131.
The implementation adds an optional
methodfield to resource rules that allows filtering by HTTP verbs (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS). Rules without a method specified will continue to match all HTTP methods, so existing configurations remain fully compatible.This should address the use case you described - you can now create separate rules for GET requests (public access) and POST/PUT requests (authenticated access) on the same path.
The changes include updates to both the database schema and UI, along with support for YAML-based blueprint configurations.
Let me know if you have any questions or feedback on the implementation.
@thutex commented on GitHub (Dec 21, 2025):
@djcrafts would this feature also be something you could add by any chance? https://github.com/orgs/fosrl/discussions/2109
(i made it a feat. request discussion because it is not really an 'issue', more of a (very welcome) addition to the rules.
and i see a use case in this situation as well, for example, to set "method get AND ip from country x", so am wondering if you think this is something doable for your commit ?
@djcrafts commented on GitHub (Dec 21, 2025):
@thutex Thanks for pointing this out! I’ve extended #2131 to support AND conditions, so you can now combine method with multiple predicates in a single rule (e.g., PATH + COUNTRY + method=GET), and existing single-condition rules still work. I also fixed the analytics chart typing issue I introduced—Recharts’ legend/tooltip expect a payload-props render function, so TypeScript complained; forwarding the payload props resolved it. All changes are pushed