chore: Add unauthenticated API integration test

[sichanyoo]

Issue #

• Integration test for unauthenticated AWS API calls #1677

Description of changes

• Adds an integration test for an API call that doesn't use authentication

New/existing dependencies impact assessment, if applicable

Conventional Commits

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[dayaffe]

should we check that the deserialized response contains expected results?

[sichanyoo]

sure, though reaching line 49 would mean the operation succeeded without throwing error, it wouldn't hurt to check it. Adopting suggestion.

[jbelkins]

The point of this is to prove that unauthenticated requests can be performed successfully. But the machine performing integration tests will have a set of AWS credentials configured for use in all the other tests.

How do we show that this request was generated unauthenticated, and isn't just succeeding because there happen to be credentials on the machine?

[sichanyoo]

@jbelkins

We know for sure that the operation used in this new integration test doesn't use authentication and is sending an unauthenticated request because the generated auth scheme resolver for CognitoIdentity's getId operation returns only a single auth scheme smithy.api#noAuth. (see here).

This means when the auth scheme gets resolved during runtime, it resolves as a "no-auth" auth scheme in AuthSchemeMiddleware here, which then subsequently results in no signing occurring during SignerMiddleware here.

---

Edit:

Added sanity-check for checking that request is indeed unauthenticated using an interceptor, after offline discussion.

[jbelkins]

A check was added to the test to ensure that the HTTP Authentication: header is not set when making an unauthenticated request. In response, I have approved.