Is this function able to figure out if the string that it's reading actually is encoded?

Yes, the usual way to verify if a string is encoded in Go is to call DecodeString and check if err == nil.

hmm, I'm not sure if it is 100% reliable

	encoded := "ZW5jb2RlZCBzZXJ2aWNlIGFjY291bnQga2V5"

	if decodedToken, err := base64.StdEncoding.DecodeString(encoded); err == nil {
		fmt.Println(string(decodedToken))
	}

	notencoded := "encodedserviceaccountkey"

	if decodedToken, err := base64.StdEncoding.DecodeString(notencoded); err == nil {
		fmt.Println(string(decodedToken))
	}

Both of these print for me (no error) and the second one is not base64 encoded string.

The error is returned when there are spaces or other non alphanumerics in the string.

The second one (decoding of not-encoded string) is producing garbage string but it seems it is a "valid" string.

I got your point, that makes sense. I believe your test has this behavior because "encodedserviceaccountkey" is a "valid" base64 encoded string in terms of structure.

The main point is when an actual service account key json is provided the DecodeString function will fail and an error is going to be returned.

Another option (that I'd like to avoid if possible) would be to add a different field for the base64, like GAE_CREDENTIALS_B64. I'd like to avoid this approach because it unnecessarily changes the plugin interface. But I'm not totally against it.

You're right that this should work in this type of field case.

I wonder if it would be helpful to indicate somehow to the users (log to the console) that decoding failed and it's going to be using the value as is. I'm thinking about cases where someone puts in invalid b64 string e.g. with extra whitespace at the end or similar (which was happening in the past).
The b64 values will come from an external source, not users in this use case, but who knows how people will use it in the future.

It may also be an overkill and what we have in the PR is good enough.

That makes sense. I'll add the log output. It will definitely make it easier to debug when someone puts in an invalid base64 string.

Just a thought: how about if you check the credential can be unmarshalled into it's JSON structure first? If it doesn't, then try decoding it and unmarshalling?

That way you are doing validation for both structure types.

Hey @tonglil, I'm so sorry I haven't seen your comment before merging - just seeing it now. I think this is a good validation to have. In any case, the best validation is going to be provided by the gcloud command when it tries to activate the service account. I'm happy to add the JSON structure validation if that makes sense, tho.

Nah you're right, let's let gcloud do the heavy lifting