Oct
19
Written by:
Joe Brinkman
Friday, October 19, 2007 9:12 AM
As part of getting ready for my PowerShell session at OpenForce '07, I am creating a set of helper functions for working with SMO to manipulate and query the database server. A common need when working with the database is to pass the username and password to various SMO methods. When I first started coding my examples, I just passed a username and password as parameters into my functions. This works, but does not exactly look professional when you are sitting in a presentation and typing out passwords in plaintext.
I decided that it would be better to use Get-Credential in this case since it would provide a professional dialog and keep the password hidden throughout the process. Since I wanted to support both scenarios, I came up with the below function.
function global:get-sqluser($username="", $password="") {
# We are creating an object to which we'll add custom properties
$user = New-Object Management.Automation.PSObject
if ($username -eq "") {
# No username was specified, so we should use Get-Credential to prompt for a user
# We also define a default username in order to suppress console output
# The results are added as synthetic properties to the PSObject we created above
$cred = Get-Credential "SqlUser"
$user.psobject.members.add(
(New-Object System.Management.Automation.PsNoteProperty UserName, $cred.username.split("\")[1]) )
$user.psobject.members.add(
(New-Object System.Management.Automation.PsNoteProperty Password, $Cred.Password) )
} Else {
# In this case we can just create synthetic properties using the values passed to the function
$user.psobject.members.add(
(New-Object System.Management.Automation.PsNoteProperty UserName, $username) )
$user.psobject.members.add(
(New-Object System.Management.Automation.PsNoteProperty Password, $password) )
}
# Return our synthetic object
$user
}
It is not perfect as the two cases return the password as either a cleartext string or a securestring. Also, I don't like the hack with the Get-Credential since I don't really need a domain qualified name (notice the ugly split("\")[1] that is needed to get just the username without a domain qualifier). My next version will resolve both of these issues, but for now this will have to suffice.
5 comment(s) so far...
Re: Getting a Username/Password in PowerShell
We can add member to object using the built-in add-member cmdlet:
$user | add-member -name UserName -value $cred.username.split("\")[1] -membertype NoteProperty $user | add-member -name Password -value $cred.password -membertype NoteProperty
By aleksandar on
Tuesday, October 16, 2007 6:25 PM
|
Re: Getting a Username/Password in PowerShell
See my next blog entry for the reason why I don't use add-member in this case.
By jbrinkman on
Wednesday, October 17, 2007 7:47 AM
|
Re: Getting a Username/Password in PowerShell
Yeah, I was going to comment on the code formatting, but it seems you noticed and fixed it.
By marco.shaw on
Thursday, October 18, 2007 5:59 PM
|
Re: Getting a Username/Password in PowerShell
$cred.GetNetworkCredential().username will give you just the username without a domain qualifier.
By aleksandar on
Monday, November 05, 2007 11:48 AM
|
Re: Getting a Username/Password in PowerShell
@Alesandar - Thanks for the info. This really highlights the need for maintaining consistency across APIs. I am used to web APIs in .Net which decompose objects properties on the top level object without requiring further method calls. You live and you learn I guess.
By jbrinkman on
Monday, November 05, 2007 11:51 AM
|