Powershell: Get-Credential Ability to Override Username

[cpmcgrath]

Summary of the new feature/enhancement

Back in Powershell 5, I could write a script which contained:

> $cred = Get-Credential -UserName "$first.$last"

A dialog would then appear, asking for the password, but it also gave the option of changing what the username was. This was useful as you could implement a naming standard, but when there was an edge case allowed the end user to be able to easily override it.

This workflow could be built into many scripts wanting to upgrade from Windows Powershell to Powershell 7.

Proposed technical implementation details (optional)

Reading #10625 I thought a -ConfirmUserName switch would be consistent, but a -DefaultUserName Username string would work just as well.

The below is how I saw it being used, being consistent with other command line tools

> $cred = Get-Credential -UserName "john.smith" -ConfirmUserName
> $cred = Get-Credential -DefaultUserName "john.smith"
PowerShell credential request
Enter your credentials.
User [john.smith]: 

The User can just press enter without typing anything and it will use the default value.

It would be nice if the value was presented as pre-typed - as this would allow the user to manipulate the value instead of either choose the default, or write it again from scratch.

[iSazonov]

I like DefaultUserName.

@cpmcgrath Do you want to implement this proposal and #10625?

[oumolayna]

hello people ,
i'm new to github so i didn't know where to post this ... but i would like to talk about something regarding the new ternary operators and other operators ...
Well the reason that made me and many others like me to love powershell is because of its English-Like cmdlets ... like jeffery said " you think about something you type it and you get it " and that really works ... the newly added operators are more like other programming languages and i hope that powershell team are not going that road ... please keep powershell cmdlets simple as they were English-Like ...
again sorry i know im posting in the wrong thread im just new here.

[iSazonov]

@oumolayna You can new issue with feedback for discussion.

[cpmcgrath]

I'd be happy to look at implementing this, but it will probably be a few weeks before I get the chance

[cpmcgrath]

Just reading through the code to this MshHostUserInterface has an overload which takes options through an enum PSCredentialUIOptions. The implementation in ConsoleHostUserInterfaceSecurity doesn't do anything with these options.

There's 4 different enum values:

• None - "Performs no validation"
• ValidateUsernameSyntax - the default: "Validates the username, but not its existence"
• AlwaysPrompt - "Always prompt, even if a persisted credential was available"
• ReadOnlyUsername - "Username is read-only, and the user may not modify it."

This seems like the mechanism that should be used, and these values imply to me that the default behaviour should be give the user a chance to override the Username

[iSazonov]

I think we can use the enum.
Changing the default behavior and changing the default enum value is two breaking changes. We will need approval from PowerShell Committee. I thing we can postpone the request until PR will be pulled.

[cpmcgrath]

As mentioned in my original comment, having it prompt for the Username regardless would make it more consistent with Windows Powershell.

But yes, potential breaking change if you had redirected Standard In. I'd think that would be very low risk though

[cpmcgrath]

Proposed change in https://github.com/cpmcgrath/PowerShell/commit/0a12184ca4985d6ba4f6b1c863d0fca33a5e79c5

I'll hold off making a pull request until I get feedback if this is the solution we're after.

[iSazonov]

I'll hold off making a pull request until I get feedback if this is the solution we're after.

Please make PR - we can discuss there and get progress step by step.
My first comment is if now we use the enum we should think to address all scenarios - it would be great to have for SDK scenarios.