Problem with expansion of %{Ldap-UserDn} containing UTF-8 (cf. Bug #411)

Enrik Berkhan enrik#freeradius at
Mon Aug 27 19:14:00 CEST 2007


Alan DeKok wrote:
> Enrik Berkhan wrote:
>> Never post before doing at least _some_ testing :)
>   Try this patch.  Untested, but it builds. :(
>   It also deals with overlong characters, and illegal use of surrogates.


And it actually starts to work :)

- I'd add a length parameter and check for str to utf8_char().

- line 167(?) of src/lib/print.c should read

    ((utf8 = utf8_char((uint8_t *)str)) == 0)) {

    instead of

    ((utf8 = utf8_char((uint8_t *)in)) == 0)) {

- for testing with HEAD I had to disbable the special case

    delimitst < 0

    in vp_prints_value(). May be this can be eliminated then.

And when testing, with a simple test setup like the following, remember
that the escaped stuff may show up in the debug output only, as packet
values will be translated back before being sent (is this correct? At
least looks so ... )

Test setup, very simple again, thanks to unlang:

strings {
    utf8 = blä
    latin1 = blä
server {
authorize {
    update reply {
      Reply-Message := "%{config:strings.utf8}"
      Reply-Message += "%{config:strings.latin1}"

(Don't know how the two strings will show up in the mail. Suppose they
are valid UTF-8 and Latin1 ... :-)

Debug output:

Sending Access-Reject of id 110 to port 32768
          Reply-Message = "blä"
          Reply-Message = "bl\344"

(Again: the first one is valid UTF-8 at my (UTF-8-)Terminal over here)

I think with a little fixing this can make it into HEAD and 1.1.x to be
tested by others.


More information about the Freeradius-Devel mailing list