Modifications to UsePSCredentialType and AvoidUsernameAndPasswordParams rules.

[kapilmb]

No description provided.

[KirkMunro]

I'm opposed to this change. Why are you removing the ordering enforcement. It is mandatory if you want a Credential parameter to work properly. The only way you can have a -Credential parameter that accepts both string and PSCredential types as input is if you define it as follows:

[Parameter()]
[System.Management.Automation.PSCredential]
[System.Management.Automation.Credential()]
$Credential = [System.Management.Automation.PSCredential]::Empty

I added the default value to highlight that best practice as well; however, PSCredential must be defined above/before the Credential converter attribute so that the value passed in can be converted (from string) before PowerShell checks to make sure it is of type PSCredential.

[kilasuit]

I Agree with @KirkMunro as this would be essentially reverting work done in #391

[kapilmb]

@KirkMunro In #391, you mention that a function will return error if CredentialAttribute precedes PSCredential, but I am not able to reproduce the error. Consider the following.

Function Get-Credential1
{
    Param(
        [Parameter(Mandatory=$true,
           ValueFromPipelineByPropertyName=$true,
           Position=0)]
        [System.Management.Automation.CredentialAttribute()]
        [PSCredential] 
        $Credential
)   

Write-Output $Credential.GetType().FullName
Write-Output $Credential.UserName
Write-Output $Credential.Password
}

Function Get-Credential2
{
    Param(
        [Parameter(Mandatory=$true,
           ValueFromPipelineByPropertyName=$true,
           Position=0)]
        [PSCredential]      
        [System.Management.Automation.CredentialAttribute()]
        $Credential
)   

Write-Output $Credential.GetType().FullName
Write-Output $Credential.UserName
Write-Output $Credential.Password
}

Get-Credential1 -Credential "someuser" and Get-Credential2 -Credential "someuser" behave identically - a credential request window pops up which returns the credential type.

Since the order doesn't seem to make any difference why should we enforce it?

[KirkMunro]

Have you tried that in downlevel versions of Windows running PowerShell 2, 3 and/or 4? In those versions of PowerShell, order matters. In PowerShell 5+, conversion attributes are processed before type attributes, so order doesn't matter. Since downlevel versions are still around and in use, it's better for the community if order is enforced on this rule, regardless of the version of PowerShell that is being used. Once PowerShell version 5 becomes the minimum supported version for PSScriptAnalyser, then the order enforcement can be removed without issue.

[kapilmb]

@KirkMunro You are right. On versions 3 and 4, Get-Credential1 -Credential "someuser" indeed gives an error.

As the rule is applicable to v3 and v4 but not to v5, I agree that we shouldn't remove the ordering enforcement. However, given that the rule is not applicable to v5 it will only cause noise within v5 context. My suggestion then would be to keep the ordering but change the error message stating that the warning is applicable only to v3 and v4.

[KirkMunro]

Changing the error message is fine with me. I just didn't want the ordering enforcement work to be undone.

[kapilmb]

Closing the pull request as the issue we were addressing was not completely examined.