1

Why can't Powershell update objects which contain extended ascii in their names ?

A powershell script has been created which uses the Invoke-RestMethod to perform a /Config/FindObjectsOfClass query for certificate objects via the VTPP RestAPI.

The script executes successfully and returns a list of VTPP DNs that represent config certificate objects matching the specified criteria.

The script then steps through each of those returned DNs and attempts to perform a /Config/Write on each DN.  However, if any of those DNs contain an extended ascii character (eg. dash x0150) then the VTPP rest api  returns a 400 ObjectDoesNotExist error. 

The object, does in fact exist though and the user used for RESTAPI authentication does have access to the object.

6 comments

  • 0
    Avatar
    Dennis Hanuska

    I should have mentioned the Worse case scenario which is that we don't receive an "objectNotFound" error but in fact map to a different object.

  • 0
    Avatar
    Walter Goulet

    This sounds very similar to the issue described in this TechNet article: https://social.technet.microsoft.com/Forums/windows/en-US/d795e7d2-dcf1-4323-8e06-8f06ce31a897/bug-invokerestmethod-and-utf8-data?forum=winserverpowershell . That article implies that the encoding used by the Invoke-RestMethod call uses a default character set for encoding data sent to the webservice. Could you try including the character set encoding explicitly in the 'ContentType' header like this: 

    Content-Type: text/html; charset=utf-8

    So in your PowerShell script, you would invoke the method as follows:

    Invoke-RestMethod -ContentType "application/json; charset=utf-8"

    to send the data over as unicode. I would also be curious to see the headers sent by the working tools to see if they are setting the Content-Type header explicitly.

  • 0
    Avatar
    Dennis Hanuska

    It would be nice if it was the solution was that simple.  Explicitly setting the character set in the header and even writing the received packet out to file made no difference.  His problem appeared to be with the reception of the data.  This problem is with the sending of the data. The reception works fine and when dumped out to a file correctly reflects the DN as it is stored in VTPP.

    This does appear to be an encoding issue.

    The RESTAPI does specify the UTF_8 character set in the headers.

  • 0
    Avatar
    Walter Goulet

    True, so I tackled the problem a different way and decided to try and the JSON payload before passing it to the Invoke-RestMethod call. By converting the JSON string from UTF8 to the Unicode encoding using the .NET System.Text.Encoding method, I was able to get the API to update the objects with names using extended ASCII characters. In my sample, the $app.DN is the DN of a basic application object with the long hyphen embedded in the name. If the sample works corrrectly, it will query the REST API to enumerate attributes of the application object. If Config/ReadAll succeeds (Result = 1), then it will use Config/WriteDN to set the 'Disabled' parameter to false.

    Try this snippet and see if it works for you:

    $uri = $VEDConnection.baseURI + '/Config/ReadAll?apikey=' + $VEDConnection.APIKey
    $tmp = @{ObjectDN=$app.DN} | ConvertTo-Json
    $json = [System.Text.Encoding]::Convert([System.Text.Encoding]::UTF8,[System.Text.Encoding]::Unicode,[System.Text.Encoding]::UTF8.GetBytes($tmp))

    $results = Invoke-RestMethod -Uri $uri -Body $json -Method Post -ContentType 'application/json' -Verbose:$showRestMethodVerbose
    if($results.Result -eq 1)
    {
    $uri = $VEDConnection.baseURI + '/Config/WriteDN?apikey=' + $VEDConnection.APIKey
    $tmp = @{ObjectDN=$app.DN;AttributeName='Disabled';Values=@(0)} | ConvertTo-Json
    $json = [System.Text.Encoding]::Convert([System.Text.Encoding]::UTF8,[System.Text.Encoding]::Unicode,[System.Text.Encoding]::UTF8.GetBytes($tmp))
    $results = Invoke-RestMethod -Uri $uri -Body $json -Method Post -ContentType 'application/json' -Verbose:$showRestMethodVerbose
    }
  • 0
    Avatar
    Dennis Hanuska

    Thanks, that solution worked in my environment as well.

  • Please sign in to leave a comment.