The Wayback Machine - http://web.archive.org/web/20200526050003/https://github.com/PowerShell/PowerShell/issues/12222
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get-Credential Ability to Override Username #12222

Open
cpmcgrath opened this issue Mar 29, 2020 · 9 comments
Open

Get-Credential Ability to Override Username #12222

cpmcgrath opened this issue Mar 29, 2020 · 9 comments

Comments

@cpmcgrath
Copy link

@cpmcgrath cpmcgrath commented Mar 29, 2020

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
Copy link
Collaborator

@iSazonov iSazonov commented Mar 29, 2020

I like DefaultUserName .

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

@oumolayna
Copy link

@oumolayna oumolayna commented Apr 4, 2020

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
Copy link
Collaborator

@iSazonov iSazonov commented Apr 4, 2020

@oumolayna You can new issue with feedback for discussion.

@cpmcgrath
Copy link
Author

@cpmcgrath cpmcgrath commented Apr 5, 2020

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

@cpmcgrath
Copy link
Author

@cpmcgrath cpmcgrath commented Apr 10, 2020

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
Copy link
Collaborator

@iSazonov iSazonov commented Apr 10, 2020

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
Copy link
Author

@cpmcgrath cpmcgrath commented Apr 10, 2020

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 pushed a commit to cpmcgrath/PowerShell that referenced this issue Apr 10, 2020
…s the ReadOnlyUserName option is passed in, it will always prompt for a UserName.
cpmcgrath pushed a commit to cpmcgrath/PowerShell that referenced this issue Apr 10, 2020
…s the ReadOnlyUserName option is passed in, it will always prompt for a UserName.
@cpmcgrath
Copy link
Author

@cpmcgrath cpmcgrath commented Apr 10, 2020

Proposed change in cpmcgrath@0a12184

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

@iSazonov
Copy link
Collaborator

@iSazonov iSazonov commented Apr 11, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.