I'm interfacing with an API with PowerShell Invoke-RestMethod cmdlet.
One of the API endpoints requires the method "Link", however this method is not supported by Invoke-RestMethod.
With CURL it is working fine
Is there a way around this?
Error message:
Invoke-RestMethod : Cannot bind parameter 'Method'. Cannot convert value "LINK" to type "Microsoft.PowerShell.Commands.WebRequestMethod". Error: "Unable to match the identifier name LINK to a valid enumerator name. Specify one of the following enumerator names and try again:
Default, Get, Head, Post, Put, Delete, Trace, Options, Merge, Patch
In PowerShell v6+, Invoke-WebRequest has a parameter CustomMethod.
This can be used with the Request Method required by the endpoint is not an available option on the -Method.
Look at the MS documentation on how to use custom method in invoke-webrequest
Update
You can use .Net class WebRequest to send your request as follows, and this will work on any PowerShell version:
$req = [net.webrequest]::create('https://www.google.com')
$req.Method = 'LINK'
$resp = $req.GetResponse()
Look here for further information
Related
I am running this code and its not returning the data to my $response variable as I expected.
$targetUrl = "https://www.tigerrunresort.com/vacation-rentals-homes-search.asp?txtStartDate=8%2F1%2F2022&txtEndDate=8%2F7%2F2022&categoryid=11317&destinationID=0&communityID=0&amenBedrooms=-1&maxPersons=0&advs=&sort=0¤tPage=1&flexibleDates=0&flexibleDatesThreshold=&searchAmenities=&showOnlySpecials=0"
$Response = Invoke-WebRequest -Uri $targetUrl
In rawcontent I should expect to see the string "Sorry" which does not show. What do I need to do to get it to return the values as I would see interactively?
Thanks!
You are not seeing it because it is not actually in the response. It is probably created and appended to the DOM by Javascript. Due to the Invoke-WebRequest not executing Javascript, it is never part of the response. If you are looking to orchestrate browsers (which do execute Javascript and offer access to the DOM) maybe you can try taking a look at Selenium (https://www.selenium.dev/)
For lauching a web request you can use for example start-process like this : start-process microsoft-edge:http://google.com/
I'm using query string parameters in a Graph API request to fetch users from Azure AD, however none appear to be working when I execute it through Powershell.
Here's the documentation on the API: https://learn.microsoft.com/en-us/graph/query-parameters
Here's some details about the scenario:
The request: https://graph.microsoft.com/v1.0/users?$top=999&$select=userPrincipalName
Executed via Powershell using the Invoke-RestMethod command
It seems to work when I use the Graph Explorer: https://developer.microsoft.com/en-us/graph/graph-explorer
I assume your app registration is set up properly and you have given the appropriate permissions etc. got the token and make the restmethod call, and the call returns full user profiles and not just the upn. It would be helpful if you provided some code. Assuming the above, from the little additional info, probably powershell is replacing your $top and $select with blank or something, because it will likely treat those as powershell variables instead of literally put them in the request url. meaning you probably did something like invoke-restmethod -Uri "graphurl?$top=etcetc" change that to single quote to take the literal string eg. invoke-restmethod -Uri 'graphurl?$top=etcetc'
I have an MS Graph API in PowerShell working for the most part.
I am using
$Uri = $null
$Uri = "https://graph.microsoft.com/v1.0/users?$select=displayName,givenName,postalCode"
$payload=$null
$payload = Invoke-RestMethod -uri $Uri -Headers $Header -Method Get -ContentType "application/json"
$payload.value
however, it is not changing the field selection. It keeps returning the default fields as demonstrated here
https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0&tabs=http
What could I possibly be doing wrong?
I am using application based authentication. The payload is being returned but it is not recognizing the $select statement.
No errors are being returned by the PowerShell
I run it in Graph Explorer it works fine.
The error is caused by the type of string declaration used for the Uri string. You are declaring the string like this:
$Uri = "https://graph.microsoft.com/v1.0/users?$select=displayName,givenName,postalCode"
This tells Powershell, that you want to evaluate the string. $ is Powershell's variable identifier. Undeclared variables are set automatically to an empty string, when evaluated in a string. Therefore the request executed against the Graph Api is:
https://graph.microsoft.com/v1.0/users?=displayName,givenName,postalCode
Your can check this yourself by writing the variable to the host:
Write-Host $Uri
If you execute this query with the Graph Explorer. It will return all users without an applied filter, which is the behaviour you have observed. You need to change the declaration to:
$Uri = 'https://graph.microsoft.com/v1.0/users?$select=displayName,givenName,postalCode'
Then, Powershell will not interpret $select as a variable and your request should work properly.
I have one function that obtains an OAuth 2 token and assembles a header; and others that use the header to make various requests to Microsoft Graph.
The function that assembles the header has two methods: one is interactive with a device code flow; and the other is non-interactive with a username and password flow.
Both methods produce a header that looks the same. The token object and the header object are the same types of object in both cases.
But, when the header is used in another GET function, the function fails in the interactive case and succeeds in the non-interactive case. The error is: "Cannot convert 'System.Object[]' to the type 'System.Collections.IDictionary' required by parameter 'Headers'."
The object returned by the header function is an array (object, base type: system array) in the failed case. It is a hashtable (hashtable, base type: system object) in the successful case. Even though, internally in the function, the token and the header are the same type. Token is System.Management.Automation.PSCustomObject, and header is hashtable.
The code that assembles the header is: $authHeader = #{
'Authorization' = "Bearer $( $tokenResponse.access_token)"
'Content-Type' = "application/json"
'ExpiresOn' = $( $tokenResponse.expires_in)
The access tokens are both long strings contained in the token response. They seem similar, and both decode OK at jwt.io.
Any ideas why two headers that look the same would be different object types, and how to get the failed one into an IDictionary format?
Found it. A prompt for input in the interactive authentication added an empty string to the output. Solution was to add | Out-Null to the prompt.
I am starting to use PowerShell to call the Azure DevOps REST API. But it seems like when I try to add parameters it tell me:
A parameter cannot be found that matches parameter name
'repositoryId'
Here is what my call looks like in PowerShell. If I take out the parameter it works. What am I doing wrong?
Invoke-RestMethod -Uri 'https://dev.azure.com/{organization}/{project}/_apis/build/builds?api-version=5.1' -repositoryId $repoId -Headers (my authentication) -Method Get
Per Microsoft's documentation this should work.
https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/list?view=azure-devops-rest-5.1
repositoryId should be url parameter as Booga Roo mentioned. The error indicated that Repository type is missing.
You should add another parameter to your uri repositoryType={repositoryType}.So the uri should be like below.
Please check here for all repositoryTypes
https://dev.azure.com/{Organization}/{Project}/_apis/build/builds?repositoryId={id}&repositoryType=TfsGit&api-version=5.1
Addition:
You can get your repositoryId from URL of Repositories page under Repos in the Project Settings. Check below screentshot.
The Invoke-RestMethod cmdlet does not have a -repositoryId parameter. The phrasing and examples on the help page are for "URI Parameters" instead of PowerShell parameters. It means you need to build it into -Uri value instead of trying to use it directly.
I suggest using this:
Invoke-RestMethod -Uri "https://dev.azure.com/{organization}/{project}/_apis/build/builds?repositoryId={$repoId}&api-version=5.1" -Headers (my authentication) -Method Get
Side note: There are double quotes around this example URI. This is so the variable expansion for $repoId will occur and be properly interpreted as part of the URI. Using single quotes as in the original example will prevent this and treat it as a literal string value and won't perform any subsitutions.