On Thu, Jan 13, 2005 at 11:55:40AM -0500, Brian Fennimore wrote: > I'm having a problem with freeradius interpreting special characters > incorrectly. It's translating the UTF-8 to some kind of quoted-printable > form when it prepares the information for accounting.
You could add the relevant bytes to the safe-characters configuration entry in the sql configuration, but that'd be pretty daft. Is UTF-8 generally safe in SQL? I always thought SQL was ASCII, with anything else being DB-server specific (I know postgresql lets you specify the character encoding for new databases for example). > The authentication/authorization appears to be unaffected by this. The > usernames are printing into the logs correctly and are authenticated fine by > the home server I'm proxying to. The escaping is done by the rlm_sql module, right before it passes it to the queries defined in the sql configuration. > These are two examples of entries I'm seeing in my accounting table. They > also appear as such in the sqltrace file so I do not suspect a problem on > the database side (I'm using postgres). Unfortunately the offending data > appears in two forms in the database and only in one form in my logs and I > can't explain the inconsistency. > [EMAIL PROTECTED] This appears to be the below, escaped again. I think this was fixed in either 1.0.1 or the (any time now) 1.0.2 release. > [EMAIL PROTECTED] > Login OK: [ [EMAIL PROTECTED]/cb29dec] If you add '\' to the safe-characters entry in the sql configuration, that'll fix that. And make sure '=' is there too. However, check your SQL server's documentation to be sure '\' isn't an escape character. -- Paul "TBBle" Hampson, on an alternate email client. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
