Problem
In #5052 we are introducing the new -Authentication parameter which include a terminating error when any scheme other than https:// is provided in the URI. The legacy -Credential usage currently does not offer any warnings or errors when the secrets are sent over an unencrypted connection.
This issue is to track and discuss which method to go with.
Possible Solutions
Add a warning
This solution would add a warning message (via WriteWarning()) that the use could suppress with the -AllowUnencryptedAuthentication parameter. This would likely be a non-breaking change that would simply the user politely when they use the legacy -Credential and something other than 'https://
Add an Error
This is similar to the previous but instead return an error. This could be a terminating or non-terminating error, but either would be a breaking change. A common usage of the web cmdlets is to use -ErrorAction Stop in a try/catch and this would introduce new stops for previously working code if users were sending credentials over HTTP before
Remove the legacy -Credential usage.
The new -Authentication usage has some duplication of functionality in that it does the same thing on its Basic option as the legacy -Credential usage. Legacy -Credential would only sent the Authorization header when the server present an Authorization request where the new method always sends the Authorization header (as many OAuth systems do not present auth realm). This would require some discovery and clean up. I think this is the ultimate choice, but probably not a good candidate for 6.0.0 RTM.
Problem
In #5052 we are introducing the new
-Authenticationparameter which include a terminating error when any scheme other thanhttps://is provided in the URI. The legacy-Credentialusage currently does not offer any warnings or errors when the secrets are sent over an unencrypted connection.This issue is to track and discuss which method to go with.
Possible Solutions
Add a warning
This solution would add a warning message (via
WriteWarning()) that the use could suppress with the-AllowUnencryptedAuthenticationparameter. This would likely be a non-breaking change that would simply the user politely when they use the legacy-Credentialand something other than'https://Add an Error
This is similar to the previous but instead return an error. This could be a terminating or non-terminating error, but either would be a breaking change. A common usage of the web cmdlets is to use
-ErrorAction Stopin a try/catch and this would introduce new stops for previously working code if users were sending credentials over HTTP beforeRemove the legacy
-Credentialusage.The new
-Authenticationusage has some duplication of functionality in that it does the same thing on itsBasicoption as the legacy-Credentialusage. Legacy-Credentialwould only sent the Authorization header when the server present an Authorization request where the new method always sends the Authorization header (as many OAuth systems do not present auth realm). This would require some discovery and clean up. I think this is the ultimate choice, but probably not a good candidate for 6.0.0 RTM.