Rudder

François ARMAND wrote:

Nicolas, please could you specify exactly:

- what should go in LDAP (escaped version ?)
- what chars (and how) should be escaped ?
- what the user see when he edit again an escaped string ?

• The user must see exactly what he typed in. If he enters """The cat said "hi" then left""", he should see just that, no escapes.
• The information should arrive in CFEngine with escaped around the double quote character. I don't know about other chars to be escaped.

Oh, and an escaped " in CFEngine is \".

It's important that what the user types is what is gets back when opening the form again

1. advanced users will be able to debug by looking at the content of the ldap
2. it avoids the need of migration scripts : if users where used to escaping their stuff, then it will be handled nicely.

The only char to escape is (so far) the " to be escaped as a \"

Is this really a user-story, and not a bug of our current implementation ? It seems that what can cause CFEngine to fail should be filtered upfront, no ?
More specifically, is there a case where we don't want to escape chars ? And if so, isn't that "raw" field the special case, not the other way around ?

Nicolas CHARLES wrote:

It's important that what the user types is what is gets back when opening the form again

I strongly advice that the escaped version is stored in the LDAP, for two reasons :

1. advanced users will be able to debug by looking at the content of the ldap
2. it avoids the need of migration scripts : if users where used to escaping their stuff, then it will be handled nicely.

The only char to escape is (so far) the " to be escaped as a \"

Are we sure that the escaping function is a bijection so that all escaped sentence point back to exactly one not escaped one (what is required if we want to be able to display back to the user what he wrote even if we store the escaped sentence in LDAP) ?

François ARMAND wrote:

Is this really a user-story, and not a bug of our current implementation ? It seems that what can cause CFEngine to fail should be filtered upfront, no ?

It's a kind of limitation which can be considered a bug

More specifically, is there a case where we don't want to escape chars ? And if so, isn't that "raw" field the special case, not the other way around ?

There is only one situation where we'd want to avoid escaping : when filling external files that are not promises (like when using CDP, or template files). We have only filesPermissions and processManagement in this situation
So it should be the norm, and the non-escape the exception

Nicolas CHARLES wrote:

It's important that what the user types is what is gets back when opening the form again

I strongly advice that the escaped version is stored in the LDAP, for two reasons :

1. advanced users will be able to debug by looking at the content of the ldap
2. it avoids the need of migration scripts : if users where used to escaping their stuff, then it will be handled nicely.

The only char to escape is (so far) the " to be escaped as a \"

Are we sure that the escaping function is a bijection so that all escaped sentence point back to exactly one not escaped one (what is required if we want to be able to display back to the user what he wrote even if we store the escaped sentence in LDAP) ?

I can't see how something that does " => \" and \" => " would not by a bijection (at least, when we start with valid data). If someone inserts broken data in the LDAP, and we have unescaped " there, problem will arise.
But in this case, generated promises are also invalid

I've done further checks.
\ and \\ are considered the same by CFEngine
\t or \n are not escape charactrers

but

\\"

So we should probably escape the \ also to be on the safe side.
Note : it may have an impact on reporting, as it would change the string in the report key, and we'd have to check how it would be handled by rsyslog and postgres

When this will be implemented, we should probably alter what was done there : http://www.rudder-project.org/redmine/issues/3160

The default will be to have the text automatically escaped, and a new contraint RAW will be created, for text that should no be escaped

How the escaping should be :
\ -> \\
" -> \"

The escaping will be done in cf-clerk