client.RetrieveSecret fails to retrieve secret if secretID contains a colon

[AndrewCopeland]

Summary

client.RetrieveSecret fails to retrieve secret if secretID contains a colon.

Steps to Reproduce

Steps to reproduce the behavior:

1. Create variable with ID some/secret:goes/here
2. Run client.RetrieveSecret("some/secret:goes/here")
3. The client will fail to retrieve the secret

Expected Results

A clear and concise description of what you expected to happen.

Actual Results (including error logs, if applicable)

404

Reproducible

• Always
• Sometimes
• Non-Reproducible

Version/Tag number

all

Environment setup

does apply

Additional Information

When retrieving the full ID of the variable, if it contains a ':' then it assumes the first part is the resource variable, group, policy.
The makeFullId is the problem.
https://github.com/cyberark/conjur-api-go/blob/master/conjurapi/router_v5.go#L149

As you can see it splits the secret ID and assumes the first part if the kind and the second part is the id.

conjur-api-go/conjurapi/client.go

Lines 157 to 166 in 6d8c9c1

	func makeFullId(account, kind, id string) string {
	tokens := strings.SplitN(id, ":", 3)
	switch len(tokens) {
	case 1:
	tokens = []string{account, kind, tokens[0]}
	case 2:
	tokens = []string{account, tokens[0], tokens[1]}
	}
	return strings.Join(tokens, ":")
	}

[AndrewCopeland]

Is there a reason why we are supporting fully qualified id names:
https://github.com/AndrewCopeland/conjur-api-go/blob/master/conjurapi/variable_test.go#L58-L84

I think this should be removed from the library because if my variable ID contains a : then this library will not work

[sgnn7]

@AndrewCopeland I believe that you're right - I don't see why variable retrieval should ever allow fetching a non-variable so I think this issue is valid. I think makeFullId may have some edge cases where it may be needed that will need to be considered (I can't think of any right now though) but for secret fetching it definitely seems erroneous.