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