On 23/12/13 04:23 AM, Heikki Vatiainen wrote: > On 12/20/2013 10:59 PM, Michael wrote: >> This ReplyHook definitely did the trick, except for not showing a proper >> error message. it just shows 'Proxied' as the error. Is there a way to >> change the error message? The source kinda looks like the error message >> is hard coded to be 'Proxied' so i thought maybe this could be passed to >> another AuthBy when rejected, configured to reject with a fixed message, >> and set the redirected flag in the hook? > You could do $p->add_attr('Reply-Message', ...) to push Reply-Message > attribute in the reply received from the proxy. The Reply-Message should > be logged in AuthLog if it is present in the reply. I'd say this is the > easiest way to handle error message with the hook. > > Please let us know how the simultaneous use modifications work. > > Thanks, > Heikki
The setting of the Reply-Message didn't seem to work. The error message still says 'Proxied' for when it's a DefaultSimultaneousUse error. It looks to me like this 'Proxied' error message is hard coded in the source. The only place I see this text is here: Radius/AuthRADIUS.pm: ($op, $op->{RadiusResult}, 'Proxied') Radius/AuthRADIUS.pm: $p->{Handler}->handlerResult($p, $p->{RadiusResult}, 'Proxied'); Radius/AuthRADSEC.pm: $p->{Handler}->handlerResult($p, $p->{RadiusResult}, 'Proxied'); Radius/AuthRADSEC.pm: ($op, $op->{RadiusResult}, 'Proxied') a closer look: # Send this new reply packet back to wherever the # original packet came from $op->{Handler}->handlerResult($op, $op->{RadiusResult}, 'Proxied') unless ( ($self->{IgnoreReject} && $p->code eq 'Access-Reject') || ($self->{IgnoreAccountingResponse} && $p->code eq 'Accounting-Response')); If i change the 'Proxed' text here the changes do show in the authlog. I guess having the ability to set an error test message for the AuthLog would require modifying this source? It's always nice to have a proper error message for the technical support people. But again, yes the actual DefaultSimultaneousUsecheck suggested, in the ReplyHook does seem to be working fine. > >> >> On 19/12/13 03:28 PM, Heikki Vatiainen wrote: >>> On 12/18/2013 11:43 PM, Michael wrote: >>>> I've gotten closer using an AuthBy GROUP around AuthBy RADIUS, but it >>>> seem to: >>>> >>>> 1. receive the auth request >>>> 2. proxy it to the host >>>> 3. check the session db before the reply comes back and reject if >>>> need be. >>>> 4. send the reject to the lns device. >>>> 5. send the accept from the proxy to the lns device. >>> This comes from AuthBy GROUP first evaluating all its AuthBys and then >>> doing DefaultSimultaneousUse check. When the check is done the request >>> has already been proxied to the next hop. >>> >>> You could consider a ReplyHook that does the check. I'd think something >>> like below should work. >>> >>> sub { >>> my $p = ${$_[0]}; # proxy reply packet >>> my $rp = ${$_[1]}; # reply packet to NAS >>> my $op = ${$_[2]}; # original request packet >>> my $sp = ${$_[3]}; # packet sent to proxy >>> >>> return unless $p->code eq 'Access-Accept'; >>> >>> my $limit = $sp->{ThisAuth}->{DefaultSimultaneousUse}; >>> if >>> (Radius::SessGeneric::find($op->{Handler}->{SessionDatabase})->exceeded( >>> $limit, $op->{OriginalUserName}, $op)) >>> { >>> $op->{RadiusResult} = $main::REJECT; >>> } >>> } >>> >>> Please let us know how it works. >>> >>> Thanks, >>> Heikki >>> >>> > _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator