Safe characters, old and new versions of 3.1.0

[Alan DeKok]

On Jan 7, 2016, at 8:13 AM, Franks Andy (IT Technical Architecture Manager) <Andy.Franks at sath.nhs.uk> wrote:
> We're seeing differences in the way unusual characters are handled in the older version when compared with the newer, in terms of the way variable values with certain characters are expanded.

  The older versions uses "safe_characters" to determine which characters were "safe".  The newer version uses the escape functions provided by the SQL driver.  Which is better.

  Different, but better.

> The main problem is it mucks up the SQL character writing - the frontend comes up with an odd asci character that in theory shouldn't be written according to the "safe characters" list afaics.
> I can't change what's in the ldap description field we use as the source of this attribute unfortunately - a third party system writes into it which we have no change access to.

  OK...

> Anyway, below are examples on old and new of the ldap attribute source, an example variable expansion of that attribute and lastly what goes into SQL. The examples aren't quite indentical as one is a live system that's so busy it's hard to get exactly the same string from it. Generally the string is "Amended by Directory Manager dd\mm\yyyy" in AD, but that comes over to ldap as dd\\mm?y for some reason,

  The "backslash digit" is typically used as an escape sequence for special characters.

> presumably because of weird characters in the string that look ok in AD console. What gets inserted after that into SQL is, on the old server,
>
> "Amended by Directory Manager dd(asciicode)mm(asciicode)yy"
> Which appears fine within mysql.

  And is still wrong, to be honest.

> On the new server
> 
> "Amended by Directory Manager dd\\mm?y" plus some other non-visible stuff I guess, which isn't fine. In SQL is looks like a square box, not sure of the actual ascii code.

  It's the escaping.

> This character doesn't seem to be part of the "safe characters". Also on the old server and new one, the ordinary backslash makes its way through to sql but I can't see it on the SC list.
> Any ideas?! Is there any way of replicating old behaviour or fixing the new?

  Re-write the date string in FreeRADIUS so that it uses forward slashes instead of backslashes.

  The easiest way to do this might be to use a regular expression. to parse the string into chunks, and the re-assemble the chunks:

	if (&control:Ldap-UserDescription =~ /(..).(..).(....)$/) {
		update control {
			Ldap-UserDescription := "Amended by Directory Manager %{1}/%{2}/%{3}"
		}
	}

  The simple lesson is "don't use backslashes".  The third-party system you're using is broken.  Happily, you should be able to fix it with FreeRADIUS.

  Alan DeKok.