"+" string converted to "=2B" in SQL request

[Arran Cudbard-Bell]

> On Mar 6, 2018, at 7:41 PM, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Mar 6, 2018, at 4:37 AM, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
>> Alan and I have had long discussions about the advantages and disadvantages of tainted values. I can see having to explicitly taint or escape any dynamic inputs to queries in the default config to get them to work reliably for everyone, at which point the scheme seems to lose some of its value.
>> 
>> The one big advantage is that it lets users easily control which values are escaped and which aren't via %{taint:} %{untaint:}, without needing to call explicit escape and unescape functions.
> 
>  TBH, it might be good to have something like an "update" section handle this...
> 
> 	verify {
> 		User-Name =~ /^abcd$/
> 		...
> 	}
> 
> * for regexes, *all* of the attribute has to match
> * for '==', it has to match exactly
> * all other comparisons are disallowed...
> 
>  If the attribute matches, then it's marked as "untainted".  That's likely simpler than a generic %{untaint:..} expansion.

Yeah that'd definitely be useful to do bulk validation of attributes coming in from the network.

I was thinking of %{untaint:} being used for something like:

update request {
	User-Name := "%{untaint:%{sql:SELECT * FROM blah WHERE foo}}"
}

Where the administrator explicitly trusts the result of the query.

There's minimal performance penalty because new style xlats are allowed to mutate their inputs and pass them through as outputs, so there's just some reparenting, moving between lists, and setting the taint flag to false.

-Arran
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20180307/6cbcd6db/attachment-0001.sig>