Hey everyone,
Whenever I read documentation for htable usage, and other examples of other scripts in Kamailio, htable keys are typically named:
something::something
Examples are: $au::auth_count, $ci::srcip, join::$rU
Why are there two colons (as opposed to a | )? Is this just a standard semantic thing in Kamailio? Is there something about that double character that’s unusual and easy to parse with SIP values? Or is it just what people do, and that’s a good choice to continue for all other Kamailio script writers to have understanding?
Any insight would be appreciated.
Thanks!
~Noah
Hi,
This is an arbitrary stylistic choice that is just consistently followed in the documentation examples, likely because it was written by the same person, or imitated by others. The colons are not required.
-- Alex
On Jan 8, 2023, at 1:57 PM, Noah Mehl noahmehl@gmail.com wrote:
Hey everyone,
Whenever I read documentation for htable usage, and other examples of other scripts in Kamailio, htable keys are typically named:
something::something
Examples are: $au::auth_count, $ci::srcip, join::$rU
Why are there two colons (as opposed to a | )? Is this just a standard semantic thing in Kamailio? Is there something about that double character that’s unusual and easy to parse with SIP values? Or is it just what people do, and that’s a good choice to continue for all other Kamailio script writers to have understanding?
Any insight would be appreciated.
Thanks!
~Noah __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Hello,
indeed, as Alex said, it is just a stylistic choice, the main purpose would be to use a character that is not allowed in variable names to mark the end of the variable (to avoid the use of ( ) to surround the name of the variable). Anyhow, it is not needed to use any static string as part of the key, can be only a variable, like $sht(x=>$ru); or can be only a static string, like $sht(x=>abc); or many variables and static strings: $sht(x=>$si::$rU::count). The :: is not seen as a special delimiter or anything similar, is pure static string from htable key point of view.
The choice of :: has probably relation with its usage in other languages like C++ to refer to (static) fields/methods. For me is also more friendly from human reading point of view, quite (white-)spacious, allowing to spot quickly the tokens composing the key.
Cheers, Daniel
On 09.01.23 01:45, Alex Balashov wrote:
Hi,
This is an arbitrary stylistic choice that is just consistently followed in the documentation examples, likely because it was written by the same person, or imitated by others. The colons are not required.
-- Alex
On Jan 8, 2023, at 1:57 PM, Noah Mehl noahmehl@gmail.com wrote:
Hey everyone,
Whenever I read documentation for htable usage, and other examples of other scripts in Kamailio, htable keys are typically named:
something::something
Examples are: $au::auth_count, $ci::srcip, join::$rU
Why are there two colons (as opposed to a | )? Is this just a standard semantic thing in Kamailio? Is there something about that double character that’s unusual and easy to parse with SIP values? Or is it just what people do, and that’s a good choice to continue for all other Kamailio script writers to have understanding?
Any insight would be appreciated.
Thanks!
~Noah __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
Daniel and Alex,
Thank you both for the prompt and enlightening responses :)
Happy new year!
~Noah
On Jan 9, 2023, at 4:15 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
indeed, as Alex said, it is just a stylistic choice, the main purpose would be to use a character that is not allowed in variable names to mark the end of the variable (to avoid the use of ( ) to surround the name of the variable). Anyhow, it is not needed to use any static string as part of the key, can be only a variable, like $sht(x=>$ru); or can be only a static string, like $sht(x=>abc); or many variables and static strings: $sht(x=>$si::$rU::count). The :: is not seen as a special delimiter or anything similar, is pure static string from htable key point of view.
The choice of :: has probably relation with its usage in other languages like C++ to refer to (static) fields/methods. For me is also more friendly from human reading point of view, quite (white-)spacious, allowing to spot quickly the tokens composing the key.
Cheers, Daniel
On 09.01.23 01:45, Alex Balashov wrote:
Hi,
This is an arbitrary stylistic choice that is just consistently followed in the documentation examples, likely because it was written by the same person, or imitated by others. The colons are not required.
-- Alex
On Jan 8, 2023, at 1:57 PM, Noah Mehl noahmehl@gmail.com wrote:
Hey everyone,
Whenever I read documentation for htable usage, and other examples of other scripts in Kamailio, htable keys are typically named:
something::something
Examples are: $au::auth_count, $ci::srcip, join::$rU
Why are there two colons (as opposed to a | )? Is this just a standard semantic thing in Kamailio? Is there something about that double character that’s unusual and easy to parse with SIP values? Or is it just what people do, and that’s a good choice to continue for all other Kamailio script writers to have understanding?
Any insight would be appreciated.
Thanks!
~Noah __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
I know that Noah knows this, but it bears reminding for posterity that one should be careful with using unsanitised bare PV values as keys, for reasons that are conceptually similar to the problem of SQL Injection.
-- Alex
Being careful about sql injection is important for security, but It should not be the case for htable when using db_mysql, because htable uses the internal sql-insert db api and the values are escaped automatically using mysql_real_escape_string(). The db_postgres connector uses PQescapeStringConn(), iirc db_unixodbc has a modparam for common escaping.
Of course, if htable is not defined to write to database, then no concern at all about the key or value and sql injection.
On the other hand, it is important to do safety checks when using directly sql_query()/sqlops in the config.
Cheers, Daniel
On 09.01.23 22:06, Alex Balashov wrote:
I know that Noah knows this, but it bears reminding for posterity that one should be careful with using unsanitised bare PV values as keys, for reasons that are conceptually similar to the problem of SQL Injection.
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
No, I meant for example: if $sht(tbl=>$rU) leads to something important, like a deletion of something else, and the caller can set $rU arbitrarily...
— Sent from mobile, apologies for brevity and errors.
On Jan 10, 2023, at 3:35 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Being careful about sql injection is important for security, but It should not be the case for htable when using db_mysql, because htable uses the internal sql-insert db api and the values are escaped automatically using mysql_real_escape_string(). The db_postgres connector uses PQescapeStringConn(), iirc db_unixodbc has a modparam for common escaping.
Of course, if htable is not defined to write to database, then no concern at all about the key or value and sql injection.
On the other hand, it is important to do safety checks when using directly sql_query()/sqlops in the config.
Cheers, Daniel
On 09.01.23 22:06, Alex Balashov wrote: I know that Noah knows this, but it bears reminding for posterity that one should be careful with using unsanitised bare PV values as keys, for reasons that are conceptually similar to the problem of SQL Injection.
-- Alex
-- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com