On 26/09/12 00:18, Matthew Newton wrote:
On Tue, Sep 25, 2012 at 09:49:53PM +0100, Matthew Newton wrote:
On Tue, Sep 25, 2012 at 06:08:04PM +0100, Phil Mayers wrote:
I did think about this myself; one option is to call rad_postauth manually if rad_authenticate(fake) fails in peap.c - which I guess is the easy/obvious solution you're referring to? Certainly preferable to the current situation IMO.
Yes. I'm just testing that to see if it behaves as expected - will post a patch for discussion if it seems OK.
Righto, finished hacking something together on master - pushed it to
https://github.com/mcnewton/freeradius-server/commits/rad_virtual_server
There are three small commits -
1. move rad_postauth (for accept) from the end of the rad_authenticate function to next to the rad_postauth called for reject in process.c. This means that rad_authenticate never calls rad_postauth - it always has to be called explicitly.
Out of curiosity, was there any reason you took this approach rather than moving rad_postauth back into rad_authenticate? The reason I ask is that rad_authenticate already calls the "authorize {}" and "authenticate {}" blocks, so symmetry would seem to suggest it call the "post-auth {}" block too. The other thing is that this change moves the execution context for the vast majority of post-auth calls (since most auths succeed). That might not matter, although I'm not sure about which thread request_finish executes in, or if it matters.