Re: Matching a prefix in huntgroups file
On 06/11/2016 17:48, Alan DeKok wrote:
I am VERY wary of putting automagic casting rules in.
I absolutely agree: the more explicit and the less magic, the better. I would rather see an immediate failure with type error than silently continuing with unexpected behaviour. I understand that in FreeRADIUS 4, to reference an attribute you will always have to include the '&'. Are you also going to require that a string literal must be enclosed in double quotes? I think that would be a good idea. In particular, it would protect against accidentally missing an '&', which could otherwise mean that e.g. if (Service-Type == Login-User) # missing '&' is interpreted as if ("Service-Type" == "Login-User") # -> always FALSE But it also means that an unquoted literal like 1.2.3.4 or 1.2.3.4/30, even on the LHS, could be unambiguously parsed as an ipaddr or ipv4prefix respectively. Regards, Brian.
On Nov 7, 2016, at 5:52 AM, Brian Candler <b.candler@pobox.com> wrote:
On 06/11/2016 17:48, Alan DeKok wrote:
I am VERY wary of putting automagic casting rules in.
I absolutely agree: the more explicit and the less magic, the better. I would rather see an immediate failure with type error than silently continuing with unexpected behaviour.
I understand that in FreeRADIUS 4, to reference an attribute you will always have to include the '&'. Are you also going to require that a string literal must be enclosed in double quotes? I think that would be a good idea. In particular, it would protect against accidentally missing an '&', which could otherwise mean that e.g.
We'll look into it. We're re-designing a lot of other things right now.
if (Service-Type == Login-User) # missing '&'
is interpreted as
if ("Service-Type" == "Login-User") # -> always FALSE
But it also means that an unquoted literal like 1.2.3.4 or 1.2.3.4/30, even on the LHS, could be unambiguously parsed as an ipaddr or ipv4prefix respectively.
Except those are pretty much valid DNS names, too. As I said before, guessing data types works a large percentage of the time. But not always. And when it fails, it's surprising. Alan DeKok.
participants (2)
-
Alan DeKok -
Brian Candler