On 2011/09/26 11:38 PM, Alan DeKok wrote:
Johan Meiring wrote:
If the auhtentication as OK, and my perl module then decides to reject
the Authentication (by returning RLM_MODULE_REJECT),
Don't do that.
The post-auth section is for running modules AFTER the user has been
accepted or rejected. It doesn't make much sense to accept the user,
and then reject them.
Instead, reject the user earlier in the packet processing.
Hi Alan,
What you say makes sense.
My perl code used to run in the Authorisation section.
The reason I moved it "down" (to post auth), is because some of my queries
are very database intensive (complex system).
i.e.
What I had was:
1) Authorisation (using rlm_perl):
Check various stuff
If OK so far, create Cleartext-Password, else reject
2) Authentication, PAP/CHAP/whatever
What I tried to avoid was that the "check various stuff" runs if the user
supplied the wrong password.
I therefore modified the setup as follows:
1) Authorisation - Create Cleartext-Password (using rlm_mysql)
2) Authentication - PAP/CHAP/whatever
3) Post-Auth - Check the various stuff and reject (using rlm_perl)
This saves a lot of unnecesary (database) CPU cycles.
Using a "Tmp-String" works.
My post-auth now looks as follows:
post-auth {
my_perl
Post-Auth-Type REJECT {
if ("%{reply:Tmp-String-0}" != "DONTRUNAGAIN") {
my_perl
}
}
}
the perl post-auth subrouting simply contains the following:
$RAD_REPLY{'Tmp-String-0'} = 'DONTRUNAGAIN';
This works as expected.
I was just hoping for a more "elegant" solutions.
Thanks again!!
--
Johan Meiring
Cape PC Services CC
Tel: (021) 883-8271
Fax: (021) 886-7782
--------------------
Before acting on this email or opening any attachments
you should read Cape PC Service's email disclaimer at:
http://www.pcservices.co.za/disclaimer.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
