Validate request and config strings are not empty

[arthuraraujo-msft]

Helps #99

~When a caller passes unexpected characters that end up in the request URL, the library fails with unexpected errors. For example "URL rejected: Malformed input to a URL function" if a line break is passed in the product name.~

~Implementing percent-encoding for product name, config namespace, accountId and instanceId.~

PR has been repurposed to only validate that request strings are not empty.

[JeffMill]

"the library fails with unexpected errors"

Specifically what "library"? What type of "errors"? If possible, I'd rather that the service returns richer errors with a reason from its validation, than the client doing validation as:

• so these dont need to be kept in sync as we have updates to the protocol over time
• the service has the definitive (and only) source for validating parameters
• third parties that arent using SFS API will get the same information and can act on it, rather than them getting "unexpected errors".

[arthuraraujo-msft]

"the library fails with unexpected errors"

Specifically what "library"? What type of "errors"? If possible, I'd rather that the service returns richer errors with a reason from its validation, than the client doing validation as:

• so these dont need to be kept in sync as we have updates to the protocol over time
• the service has the definitive (and only) source for validating parameters
• third parties that arent using SFS API will get the same information and can act on it, rather than them getting "unexpected errors".

One such example is the one given above.

For example "URL rejected: Malformed input to a URL function" if a line break is passed in the product name.

Some patterns will just break the communication and not even allow us to reach the actual service validation.

An alternative is simply checking for the minimum patterns that allow us to establish the communication: avoiding characters not allowed in URLs.

[JeffMill]

"Some patterns will just break the communication and not even allow us to reach the actual service validation."

can you be more specific? Presumably nlohmann should do JSON string escaping, so that shouldn't be an issue. If it's due to the URL, we should be url encoding the query string. I'm guessing there's some other underlying issue here? There's not much here for me to go off of currently other than "broken communication" and "unexpected errors", and I'd like to understand the root cause to determine alternative mitigations.

[arthuraraujo-msft]

"Some patterns will just break the communication and not even allow us to reach the actual service validation."

can you be more specific? Presumably nlohmann should do JSON string escaping, so that shouldn't be an issue. If it's due to the URL, we should be url encoding the query string. I'm guessing there's some other underlying issue here? There's not much here for me to go off of currently other than "broken communication" and "unexpected errors", and I'd like to understand the root cause to determine alternative mitigations.

Product name, accountId, instanceId and namespace are part of the formed URL. If there are any chars that should not be there, the URL will be malformed.

Examples:

• Product having a "\n" character leads to "URL rejected: Malformed input to a URL function"
• Account id having a "\t" character leads to "URL rejected: Bad hostname"

Url encoding most of these might help delay the validation to the service. Still accountId would fail as it is used to form the hostname.

https://{accountId}.api.cdp.microsoft.com/api/v2/contents/{instanceId}/namespaces/{nameSpace}/names/{product}

[JeffMill]

• Product having a "\n" character leads to "URL rejected: Malformed input to a URL function"
• Account id having a "\t" character leads to "URL rejected: Bad hostname"

Yes, these should be escaped. we shouldn't be passing any unescaped data to an URL. -- see section 2 of the RFC (and I guess it's officially "percent-encoding", not url escaping)

account id should be escaped as well. if that fails, then the services should return an error from the service exactly if an unregistered account name (e.g. "invalidaccount") was passed.

[arthuraraujo-msft]

account id should be escaped as well. if that fails, then the services should return an error from the service exactly if an unregistered account name (e.g. "invalidaccount") was passed.

Sadly that is not possible. When the accountId does not exist we just can't reach the created hostname, and that leads to #125

[JeffMill]

Sadly that is not possible. When the accountId does not exist we just can't reach the created hostname, and that leads to #125

did you raise this with the service folks to investigate? I'm guessing that this is occuring because the endpoint at https://invalid_accountId.api.cdp.microsoft.com doesn't exist and api.cdp.microsoft.com isn't sending back a response, or is sending back an untrusted (e.g. wrong/invalid cert) response. In either case, the root cause should be fixed, as while you could try to work around this, we have a public REST API that needs to respond properly for all clients, and not need workarounds.

[arthuraraujo-msft]

Sadly that is not possible. When the accountId does not exist we just can't reach the created hostname, and that leads to #125

did you raise this with the service folks to investigate? I'm guessing that this is occuring because the endpoint at https://invalid_accountId.api.cdp.microsoft.com doesn't exist and api.cdp.microsoft.com isn't sending back a response, or is sending back an untrusted (e.g. wrong/invalid cert) response. In either case, the root cause should be fixed, as while you could try to work around this, we have a public REST API that needs to respond properly for all clients, and not need workarounds.

No, will raise that with them.

[arthuraraujo-msft]

Switched to percent encode the input strings using curl_easy_escape

[arthuraraujo-msft]

@JeffMill any other changes missing?