Alan DeKok wrote:
The same thing goes for "==". Having the attribute not exist is technically an exception, not a failed match.
When you put it that way, it actually becomes clearer. It seems to be quite unreasonable for == to return success if the attribute did not exist. Indeed, it only returns match if there is an attribute that exists and matches the supplied value. So to != should only return match if there was no attribute that existed and compared successfully with != value. A requirement that the attribute existed but did not match the value is not quite an inversion of == !* is properly an inversion of =*
I have tested it to an extent and would appreciate feedback.
My main concern is changing the behavior of the server.
Does this mean you think the patch would be a good idea otherwise? With some changes it can avoid changing the behavior of != !~ when no pairs are found. But is that a good idea? Perhaps a small poll to find out if anyone present relies on the current behavior of != ? Anyways, I thought you were doing a 2.0.0 :-) ? If the operator behavior is problematic, perhaps users would be best served correcting it as early as possible in the server history. So far I have seen -= , != , !* , !~ that could possibly be changed. I also have added -* , -~ operators that I find usefull, especialy in the policy module.
I'd prefer to move these kinds of checks to rlm_policy, as it's new, and won't break existing systems.
The policy module, while I managed to get it to work for my own purposes, wasnt being called complete or stable. And it stands to reason that paircompare could/should be used by all modules who wish to maintain comparable comparison rules as used in the users file and other modules. Also the policy manages to duplicate a nice portion of the paircompare() functionality within evaluate_condition(). That means two sets of code need to be maintained to present as consistent an experience to the user as possible. Additionaly, != is handled the same way in the policy module as in paircompare(), if it doesnt exist it returns FALSE. I guess what I am getting at is the impression that equaly important as being consistent with past usage should be internal consistency with current usage. Not like my opinion actually matters much.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html