[Devel] acc diff

[Dan Pascu]

On Tuesday 03 October 2006 16:39, Juha Heinanen wrote:
> Dan Pascu writes:
>  > That's exactly my point. I do NOT want to do all this avp testing
>  > and manipulation in the script. This was previously done by openser.
>  > What is the point of replicating the same logic in 99% of the
>  > openser.cfg scripts out there?
>
> because this may work for you now, but perhaps not anymore in near
> future.  what if request comes from another operator, p-a header has

It doesn't work even now, but I have a simpler way around it currently. I 
let it define User-Name as it does and if I need something else I define 
an extra attribute and set an avp for it. Then I let freeradius pick this 
extra attribute if defined else pick the standard User-Name as freeradius 
has such a fallback mechanism to the first defined variable in a list.
But this i not the point. The point is that I only set this extra 
attribute if I have to, not set User-Name all the time using the same 
logic always. We may need extra flexibility but others don't.

> been removed and replaced by p-a-i header as specified by rfc 3325 and
> from uri is anonymous?  this proves that it is plain stupid to hardwire
> caller username algorithm in the code.  i don't understand what you
> have against 4 lines of openser.cfg code.
>
>  > I would rather want to see a default for this (since almost everyone
>  > will use it) and a way to overwrite it.
>
> overwriting does not work, because i don't want to calculate any
> UserName for some requests.
>
> if people feel sick about 4 lines of openser.cfg programming, then i

4 lines here, 4 lines there. They add up. Every change that was made 
recently in openser has forced me to rewrite parts of the configuration 
and never once this rewriting simplified things, it always made them more 
complex and requiring more avp computations. That's what bothers me, not 
these 4 lines of code.

> don't see any other option than having a module parameter that tells if
> caller username should be included or not.  and if included, it should
> be included for every backend.

I already suggested something that would work and require no module 
parameter: define a pseudo variable, say $un that does the current logic 
internally when accessed (try credentials if not fail to from else be 
undefined). This way people can still easily get the old behavior and 
also easily extend it without having to write extra code if not 
necessary.

-------------------

Old behavior:
modparam("acc", "radius_extra", "User-Name=$un")

Old behavior with some extra logic:
modparam("acc", "radius_extra", "User-Name=$avp(s:billing_party)")

if (comes from PSTN-GW) {
  avp_printf("$avp(s:billing_party)", "my fancy value");
} else {
  // fallback to the default behavior
  avp_write("$un", "$avp(s:billing_party)");
}

------------------

IMO, this would provide you with all the flexibility you need and still 
permit the old behavior without any coding/complexity. And will also 
allow for more compact code when you just want to extend the default 
behavior a bit as in the second example above.

I see no reason why this approach wouldn't satisfy everyone while also 
being simple and straight-forward. $un will be computed in realtime, so 
if you don't access it it will never compute anything.

-- 
Dan