Support secrets: things that should not be saved verbatim

[docwhat]

Problem to solve

There are values that are secret and should not be saved. Even cookies that become invalid quickly should not be stored for others to see.

The specific case I have is when generating reports or when running in CI.

Proposal

I don't know enough about the innards, but from a user point of view it would be nice if there was a way to taint values.

Some example things:

• hurl --secret 'a variable that is pre-tainted' file.hurl
• Instead of variable = use secret = .
• When doing multi-step authentication, not only should the password/secret be tainted, but the captured items might need to be as well. Maybe secret :: csrf_token: xpath "normalize... (modifying the example for capturing response.

Additional context and resources

I don't think it's worth looking for matching strings; just tracking the variable should be enough.

Tasks to complete

[fabricereix]

Hi @docwhat,
thanks for your issue. This would be indeed a good feature for Hurl.
We have to think how we can add it.

[fabricereix]

@jcamiel,
We could add another field mask to the runtime String value.

For example
--variable user=bob initializes the string variable user with the value { plain: "bob", mask: "bob"}
--secret password=secret initializes the string variable password with the value { plain: "secret", mask: "*****"}

The following template {{name}}:{{value}} will be evaluated to { plain:"bob:secret", mask: "bob:*****}.
The same concatenation operation applies to both the mask and plain fields.

Anytime we need to log a string variable, we will use its mask field.

[docwhat]

Clever.

That way, you can compose strings multiple times and keep the secret secret and not have to replace the whole composed string with ****.

Otherwise, composed items become "elevated" or "tainted," meaning you'd have to replace the composed item with ***** which would be uninformative.