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