2.11.0: Invoke-MgGraphRequest Broken

[AjkayAlan]

Describe the bug
After upgrading to 2.11.0 (published in PSGallery), my calls using Invoke-MgGraphRequest all started getting 400 Bad Requests.

Downgrading to 2.10.0 fixes the issue.

To Reproduce
Steps to reproduce the behavior:

# Uninstall all old versions
Uninstall-Module Microsoft.Graph -AllVersions -ErrorAction SilentlyContinue
Get-InstalledModule Microsoft.Graph.* -ErrorAction SilentlyContinue | ? Name -ne "Microsoft.Graph.Authentication" | Uninstall-Module -AllVersions
Uninstall-Module Microsoft.Graph.Authentication -AllVersions -ErrorAction SilentlyContinue

# Install 2.11.0 which is broken
Install-Module Microsoft.Graph.Users -Scope CurrentUser -RequiredVersion 2.11.0 -Force

# Auth up
Connect-MgGraph

# Make the call (which fails) - Note the ID corresponds to an Entra group, I have obfuscated here.
Invoke-MgGraphRequest -Uri 'v1.0/me/memberOf?$filter=id eq ''abcdefgh-ijkl-mnop-qrst-uvwxyz123456'''

Expected behavior

The API should return the result if I belong to the group id passed, or return a 404 if I don't.

Debug Output

I am intentionally not providing anything here since the screenshot covers it, and the debug output was no more helpful.

Module Version

2.11.0

Environment Data

Name                           Value
----                           -----
PSVersion                      5.1.19041.3693
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.3693
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Screenshots

See above

Additional context

I recognize that 2.11.0 hasn't been formally cut or set as latest in the release, but PSGallery is showing it as latest.

[randomnote1]

Thanks for opening this. I spent all day troubleshooting a function app due to this issue.

[rakheshster]

Same! I just came here to log an issue after wondering why my delta queries were not working any more.

The following URL, which is an example from the MS docs, works fine up to 2.10.0:

> Invoke-MgGraphRequest -Method 'GET' -Uri 'https://graph.microsoft.com/v1.0/groups/delta/?$filter= id eq ''477e9fc6-5de7-4406-bb2a-7e5c83c9ffff'' or id eq ''004d6a07-fe70-4b92-add5-e6e37b8affff'''

Name                           Value
----                           -----
@odata.context                 https://graph.microsoft.com/v1.0/$metadata#groups
@odata.nextLink                https://graph.microsoft.com/v1.0/groups/delta/?$skiptoken=l-ojA6nnMNq-BLHBnOZMTzMwDcHVnE3MaXWwhuSPEymw647SqK2Ds2TCTek…
value                          {}

But fails in 2.11.0:

> Invoke-MgGraphRequest -Method 'GET' -Uri 'https://graph.microsoft.com/v1.0/groups/delta/?$filter= id eq ''477e9fc6-5de7-4406-bb2a-7e5c83c9ffff'' or id eq ''004d6a07-fe70-4b92-add5-e6e37b8affff'''

Invoke-MgGraphRequest: GET https://graph.microsoft.com/v1.0/groups/delta/%3F%24filter%3D%2520id%2520eq%2520%27477e9fc6-5de7-4406-bb2a-7e5c83c9ffff%27%2520or%2520id%2520eq%2520%27004d6a07-fe70-4b92-add5-e6e37b8affff%27
HTTP/1.1 400 Bad Request
Transfer-Encoding: chunked
Vary: Accept-Encoding
Strict-Transport-Security: max-age=31536000
request-id: c9d8ff0d-101b-48a7-b9a4-e232e924a8f3
client-request-id: 089e45ce-a740-483c-aa3b-df6073f2a56f
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"xxx","Slice":"E","Ring":"5","ScaleUnit":"000","RoleInstance":"TO1PEPF00104DF8"}}
Date: Tue, 12 Dec 2023 01:57:31 GMT
Content-Type: application/json
Content-Encoding: gzip

{"error":{"code":"BadRequest","message":"The request URI is not valid. The segment 'delta' must be the last segment in the URI because it is one of the following: $ref, $batch, $count, $value, $metadata, a named media resource, an action, a noncomposable function, an action import, a noncomposable function import, an operation with void return type, or an operation import with void return type.","innerError":{"date":"2023-12-12T01:57:32","request-id":"c9d8ff0d-101b-4877-b9f4-e232e924a8f3","client-request-id":"089e45ce-0740-483c-aa3b-df6073f2a56f"}}}

Looks like the URL is getting mangled.

Thanks,
Rakhesh

[jwinterberg]

Confirming the same here, this also broke some other modules that are dependent on this (example: WindowsAutopilotIntune).
It seems to break as soon as query options are added to the URI.

Escaping those characters in the URI unfortunately doesn't help either.

[andrew-s-taylor]

I'm also seeing issues with pagination, trying to grab the next link errors out

[AjkayAlan]

FYI for those who are struggling to get 2.11.0 uninstalled, after you try the following:

Get-InstalledModule
Uninstall-Module Microsoft.Graph -AllVersions -ErrorAction SilentlyContinue
Get-InstalledModule Microsoft.Graph.* -ErrorAction SilentlyContinue | ? Name -ne "Microsoft.Graph.Authentication" | Uninstall-Module -AllVersions
Uninstall-Module Microsoft.Graph.Authentication -AllVersions -ErrorAction SilentlyContinue
Get-InstalledModule

If you still find Microsoft.Graph.Authentication hanging around you can try nuking it from the modules folder manually. To find that location, you can run the following in PowerShell: [Environment]::GetFolderPath('MyDocuments') + "\WindowsPowerShell\Modules". Then you can pop that resulting path into file explorer and try deleting the Microsoft.Graph modules manually.

[ioamnesia]

It looks like the module is urlencoding the uri so something like '/v1.0/users?$top=10' is sent to '/v1.0/users%3F%24top%3D10' which graph rejects.

[rakheshster]

Looks like 2.11.1 has fixed this.

[ioamnesia]

I looked at the source and the issue stems from a new method intended to encode the uri, but it uses very rudimentary logic that just splits the uri by the slashes and encodes anything after the https://. This inadvertently encodes query parameters. At a minimum, they'd need to split off the query params and append them after encoding the rest of the url. This looks like it was intended to handle special characters that are in UPNs like external accounts with #EXT#. The funny thing is that currently graph accepts these as is and doesn't require encoding the # symbols. That said, it may be a portent of things to come (please don't get rid of this capability)...

Note to devs, if there's a bigger reason this change is needed, you'll need to keep in mind if encoding may need to be performed on certain query parameters like $filter (e.g. /v1.0/users?$filter=userPrincipalname eq 'someone_outlook.com#EXT#@domain.onmicrosoft.com' being used instead of /v1.0/users/someone_outlook.com#EXT#@domain.onmicrosoft.com) so it's not as straightforward as just excluding all query params from encoding...

[ioamnesia]

Looks like 2.11.1 has fixed this.

Yeah, they just reverted the call to the new helper function uriBuilder.Uri.EscapeDataStrings and return the uriBuilder.Uri unaltered. Quick fix while they figure out what they're going to do next.

I'm really surprised this passed automated testing. Any tests that used a single query parameter would have caught this bug :( Just goes to show you that if the person making the change also makes the test, any blind spots will be present in both. I miss the days of dedicated test engineers. They made breaking code an art form 😆

[peombwa]

Sorry for any inconvenience caused by the bug.

A patch has been released in version 2.11.1 to address the bug that affected users of v2.11.0. The patch reverts the change that caused query parameters to be double encoded when using the command.

#1947 has been reopened to track encoding of # for external users.