'.' in profile name

[JumpyKitten]

Any profile name with a dot (a.k.a. fullstop) character is ignored.

Expected Behavior

Dot is accepted by AWS CLI, SDK for Python, Ruby, etc. (and SDK Java V1 I believe) as a valid character in profile name. So should AWS SDK for Java V2.

Current Behavior

In software/amazon/awssdk/auth/profile/internal/ProfileFileReader.java,
private static final Pattern VALID_IDENTIFIER = Pattern.compile("^[A-Za-z0-9_\-]*$");
Note that dot (a.k.a. fullstop) is excluded.

Your Environment

• AWS Java SDK version used: 2.0.0-preview-7

[jpollard-cs]

the / character should also be supported

[millems]

We're not aiming for exact parity with what the CLI supports. In particular, it has some very odd parsing rules around being able to quote strings.

What's the use-case for wanting dots and slashes?

[jpollard-cs]

@millems this appears to break compatibility with Okta as profiles are named like 671250123543/Retail-EC2-Admins/jane@company.com (see https://support.okta.com/help/s/article/Integrating-the-Amazon-Web-Services-Command-Line-Interface-Using-Okta for more info)

I could open a ticket with them here https://github.com/oktadeveloper/okta-aws-cli-assume-role#configuring-aws-in-okta, but do you mind if I ask - is there a good case not to preserve backwards compatibility in this instance?

[millems]

What we have right now seems too strict, but we can't relax it all the way to what the CLI supports, because then it's too difficult to implement in other languages. We can't be fully compatible with the CLI, so we need to settle on what we do actually intend to support.

Your example makes a good case for /, @ and ., but it seems silly to play whack-a-mole with examples. Any proposals on what you might consider reasonable support?

[jpollard-cs]

my experience here is limited so looping in some okta devs: oktadev/okta-aws-cli-assume-role#208

[AlainODea]

@jpollard-cs 671250123543/Retail-EC2-Admins/jane@company.com is STS role session name. AFAIK, the v2 SDK should have no problem with the named profile sessions https://github.com/oktadeveloper/okta-aws-cli-assume-role writes to ~/.aws/credentials. I haven't tried it yet, but I don't anticipate any problems.

UPDATE: the session name like above is used as a profile name by my code if no profile name is supplied. I’ll fix that on my end.

[jpollard-cs]

okay so this addresses my concerns @millems and I can get behind making only the minimum necessary changes in favor of cross-language compatibility 😄

@JumpyKitten anything you want to add here to make a good case for this to remain open?

[millems]

@jpollard-cs I think the case is that "." is a reasonable character to support in profile names (eg. to use domain-style addressing). I'm just hoping to figure out which other characters are also considered reasonable before we make any changes.

[JumpyKitten]

Thank you for looking into this. I would be very happy with allowing the "." character since I typically named my profiles like:
[account-a.user-1]
[account-b.user-2]

An error message instead of ignoring invalid profile names would be helpful too.

[millems]

Unfortunately ignoring invalid profile names is the CLI's behavior, so that particular behavior cannot be changed without compromising compatibility.