[+SPAM+]: Re: SQL Module: Inconsistent behavior dealing with the escaping backslash

[Kwak Wookjong]

Hi Alan,

Thanks for the respond and your suggestion.
But I am still seeing the same problem. (Additional backslash prepended)

Even though, using another table (other than NAS) for putting client information,
When, putting the information into attributes, the additional step that you described would be applied.
Then, it would make additional backslash in front of original backslash as it is not *directly* read from the table.

My question would be how can I make the value read directly from the table as it does for NAS table reading?
Or, do we need to check if the escaping is properly done when putting the information into attributes?

Best Regards,

WJ


-----Original Message-----
From: Freeradius-Users [mailto:freeradius-users-bounces+wookjong.kwak=gemalto.com at lists.freeradius.org] On Behalf Of Alan DeKok
Sent: Thursday, January 25, 2018 12:09 PM
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Subject: [+SPAM+]: Re: SQL Module: Inconsistent behavior dealing with the escaping backslash

On Jan 25, 2018, at 12:30 PM, Kwak Wookjong <Wookjong.Kwak at gemalto.com> wrote:
> I have found that the backslash in the shared secret interpreted
> differently depending on the read_clients option to be set in the
> /etc/raddb/mods-enable/sql
>
> Case 1.
> When the DB is read while its startup only, by setting read_clients
> option to be yes, for example, the shared secret, test\123 is read as
> test\123 and the client is added with having single backslash.
>
> Case 2.
> When the DB is read per each request, by setting read_clients option
> to be no, the shared secret, test\123 becomes test\\123 and the client
> is added with having double backslashes.

  That's an issue, but a minor one.  When "read_clients = yes", the clients are read *directly* from the NAS table.

  i.e. the information about the clients is not put into an attribute first.

  When you create clients manually, you're putting the information into attributes.  So there's an additional step  which is being taken.

  The short answer is that you should not dynamically pull client information from the nas_table, and put it into attributes.  The nas_table is intended to be used only when "read_clients = yes".

  If you do need dynamic clients, put their information into another table.

  i.e. each table has a specific purpose, and shouldn't be used for anything else.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.