attrs.filter differences between FR 2.2.0 and FR 3
Arran Cudbard-Bell
a.cudbardb at freeradius.org
Tue Nov 12 15:51:10 CET 2013
On 11 Nov 2013, at 20:41, Palmer J.D.F. <J.D.F.Palmer at SWANSEA.AC.UK> wrote:
> Thanks Arran,
>
>> Filters use an arbitrary key just the same as the Users-File.
>>
>> attr_filter attr_filter.post-proxy {
>> key = "%{Response-Packet-Type}.%{Realm}"
>> filename = ${modconfdir}/${.:name}/post-proxy
>> }
>>
>> May work, if it doesn't we might need to add some xlat magic to expose the
>> proxy response.
>>
>
> I think that some xlat magic might be required...
>
> (9) [post_proxy_log] = ok
> (9) attr_filter.post-proxy : expand: "%{Response-Packet-Type}.%{Realm}" -> '.jrs'
> (9) [attr_filter.post-proxy] = noop
Yes, this appears to of been missed off from the virtual attributes hack in the xlat parser.
Added it back in.
If the request has a proxy response associated with it and no reply code set, this will return the proxy response.
case PW_RESPONSE_PACKET_TYPE:
{
int code = 0;
if (request->proxy_reply && (!request->reply || !request->reply->code)) {
code = request->proxy_reply->code;
} else if (request->reply) {
code = request->reply->code;
}
return talloc_strdup(ctx, fr_packet_codes[code]);
}
If it has a reply code set, it'll return that. Should work as expected in most situations.
IIRC key had to be set for this behaviour in 2.x.x. I think <response type>.<realm> was just a neat hack I suggested in the JRS docs for the Sussex case study, and other people started using it.
Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team
More information about the Freeradius-Users
mailing list