Extra escape backslash added to AWS Eventbridge Secret

[upgradingdave]

Describe the Bug

An extra backslash character (\) is added to secrets when the secret value also contains a \+ character sequence.

This is a problem because AWS will generate secrets and sometimes those secrets contain backslashes \. If an extra backslash is added, this breaks the authentication.

Steps to Reproduce

1. Add an AWS Event Bridge Outbound Connector task to a BPM Diagram
2. Configure a value of 123\+45 into the Secret Key field of the Credentials Authentication Section
3. Deploy and run the process
4. Note that the authentication instance variable for the task has an extra backslash character added: \.

{
	"type": "credentials",
	"accessKey": "foo",
	"secretKey": "123\\+45"
}

Expected Behavior

The secret value should be sent to AWS exactly how it's entered into Web Modeler. No extra backslashes should be added.

Environment

• OS: MacOS Monterey, Chrome Version 125.0.6422.77 (Official Build) (arm64)
• Library version: Camunda SaaS Production 8.5.1
• Camunda version: Camunda SaaS Production 8.5.1

[chillleader]

@upgradingdave I wasn't able to reproduce the issue with 8.5 - although in Operate you will see the backslash with an escape character (that's a limitation in JSON that those have to be escaped), in the connector itself, the backslash is unescaped and passed to AWS in its original format. Is it possible that the authentication issue was caused by something different?

On the other hand, I found that it's not possible to use unescaped backslashes inside connector secrets. Because of how the secret replacement currently works (we serialize variables to string and replace secret syntax in that string), substituting a value that contains an unescaped backslash results in invalid json, and the value cannot be deserialized again. As a workaround, such backslash characters need to be escaped in connector secrets.

FYI @sbuettner

[sbuettner]

@chillleader I think we can close this one. WDYT?

[chillleader]

Yep, let's close it for now. @upgradingdave please feel free to reopen if you run into a similar issue again

[upgradingdave]

Yes sounds good, feel free to close. For the record: the root cause of the authentication issue for this case turned out to be something different than backslash interpretation. The customer did not realize that inbound connector secrets are only evaluated when process definitions are deployed (The secrets are not evaluated every time a inbound connector is called). When the customer redeployed the inbound connector with a properly escaped password, that fixed the issue.