5

I try to create a PSCredential object with a password that contains german umlauts and pass it to the New-WebServiceProxy cmdlet. The code works as expected as long as the password doesn't contain any umlauts like in the following example:

$secp = ConvertTo-SecureString 'abÜ312!' -AsPlainText -Force
$mycreds = New-Object System.Management.Automation.PSCredential('\user@db', $secp)
$proxy = New-WebServiceProxy -Uri "https://example.com/webservice/myWs?wsdl" -Credential $mycreds

In this case, I get the following error message:

New-WebServiceProxy : The request failed with HTTP status 401: Unauthorized.

When I capture the traffic using e. g. Fiddler, I see that the New-WebServiceProxy cmdlet is adding the credentials as Basic Authorization with a base64 encoding:

GET https://example.com/webservice/myWs?wsdl HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)
Authorization: Basic dXNlckBkYjphYtwzMTIh
Host: example.com

This is how the decoded Base64 string looks like in Utf8:

String in UTF8

So it looks like PowerShell is encoding the Umlauts as an ANSI string. When I manually base64 encode the Credentials (dXNlckBkYjphYsOcMzEyIQ== instead of dXNlckBkYjphYtwzMTIh) and reply the fiddler request, I get the desired response.

Unfortunately, I am not able to use this workaround because the New-WebServiceProxy doesn't allow me to add the Authorization header myself.

Any ideas?

marsze
  • 15,079
  • 5
  • 45
  • 61
Martin Brandl
  • 56,134
  • 13
  • 133
  • 172
  • 1
    Thät sücks. Short of avoiding usernames and passwords with non-ASCII characters, switching the whole system to UTF-8 as described in [this answer](https://stackoverflow.com/a/57134096/45375) _may_ work, but even if it does that has far-reaching consequences. – mklement0 Apr 28 '21 at 14:49
  • 2
    Can't believe it's 2021 and we still have to deal with issues like this. From a quick look at the source it seems like an implementation detail of the `WebRequest` class, or either way a .NET implementation detail, so I got no solution off the top of my head except not using umlauts, or build the proxy yourself using [other tools](https://learn.microsoft.com/en-us/dotnet/framework/wcf/servicemodel-metadata-utility-tool-svcutil-exe). – marsze Apr 28 '21 at 14:59
  • 1
    I agree with you @marsze . It's hard to believe that we still have to deal with such problems nowadays. – Martin Brandl Apr 28 '21 at 15:03
  • 2
    @MartinBrandl: Hopefully, yes - would be good to at least find out if the workaround helps. Some background info (definitely not my area of expertise): `New-WebServiceProxy` is no longer available in PowerShell (Core), though, curiously, it is still part of the source code: https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Management/commands/management/WebServiceProxy.cs. GitHub issue with a discussion: https://github.com/PowerShell/PowerShell/issues/9838 – mklement0 Apr 28 '21 at 15:05

2 Answers2

2

The linked answer from mklement0 led me to the solution:

The script was written and saved using PowerShell ISE. I just realized that ISE was saving the file using the UTF-8 with BOM encoding. If I change the encoding to UTF-8 everything works.

Here is a short script to change the encoding of a file to UTF-8:

$scriptPath = "c:/path/to/script.ps1"
$content = Get-Content -Raw $scriptPath
[System.IO.File]::WriteAllLines($scriptPath, $content, (New-Object System.Text.UTF8Encoding))
Martin Brandl
  • 56,134
  • 13
  • 133
  • 172
  • 2
    Intriguing. Just so I understand: This is a _workaround_ that relies on deliberately letting Windows PowerShell _misinterpret_ your UTF-8-encoded script as ANSI-encoded, correct? – mklement0 Apr 29 '21 at 07:30
  • 1
    @mklement0 Yes, from my tests it seems this is exactly what happens. The idea behind that is not all bad, I used it as basis for the approach in my answer. – marsze Apr 29 '21 at 07:48
2

Interesting. Your workaround led me to this more general workaround, which does not depend on saving incorrectly encoded script files. Instead, it incorrectly encodes the password string only

Let me know if this works.

$pw = 'abÜ312!'
# incorrectly encode the UTF8-bytes as ANSI (this yields abÜ312!)
$dummy = [Text.Encoding]::Default.GetString([Text.Encoding]::UTF8.GetBytes($pw))
$secp = ConvertTo-SecureString $dummy -AsPlainText -Force

I assume this will not work for any characters, but I don't know enough about encodings to say for sure.

marsze
  • 15,079
  • 5
  • 45
  • 61