I was going to knock out a quick concept patch but I see it's not a trivial patch; before I make the effort to code it I thought I'd check: It seems useful for the sql module to set the return code to RLM_MODULE_REJECT if the Auth-Type gets set to reject - the specific use case I have is an unlang policy like so: authorize { preprocess sql if ("%{reply:MyStatus}" !~ /Active|Guest/) { reject } # ...some more stuff } ...however inside the SQL I have groups with id | groupname | attribute | op | value ----+-----------+-----------+----+-------- 2 | staff | MyStatus | = | Active 3 | banned | Auth-Type | := | Reject ...and it would be nice if members of the "banned" group stopped processing early. At the moment the SQL module only returns FAIL, NOTFOUND or OK. Thoughts?
Phil Mayers wrote:
I was going to knock out a quick concept patch but I see it's not a trivial patch; before I make the effort to code it I thought I'd check:
It seems useful for the sql module to set the return code to RLM_MODULE_REJECT if the Auth-Type gets set to reject - the specific use case I have is an unlang policy like so:
It's much easier to update src/main/modules.c, function modcall(). That way, *any* module updating Auth-Type will have it's return code over-ridden to 'reject'. e.g. ... int saw_reject = FALSE; ... myresult = call_modsingle(...); if (!saw_reject && (compenent == RLM_COMPONENT_AUTH) && ((myresult == RLM_MODULE_OK) || (myresult == RLM_MODULE_UPDATED)) { VALUE_PAIR *vp = pairfind(request->config_items, PW_AUTHTYPE); if (vp && (vp->vp_integer == PW_AUTHTYPE_REJECT) { saw_reject = TRUE; myresult = RLM_MODULE_REJECT; } } ...
...and it would be nice if members of the "banned" group stopped processing early.
Yes. Reject should mean "reject NOW!" Alan DeKok.
participants (2)
-
Alan DeKok -
Phil Mayers