When I'm trying to create a new work item in VSTS with the POST request:
https://galilinetsky.visualstudio.com/Automatiom/_apis/wit/workitems/$Test%20Case?api-version=5.0-preview.2
I get the next response :
Microsoft Internet Explorer's Enhanced Security Configuration is
currently enabled on your environment. This enhanced level of security
prevents our web integration experiences from displaying or performing
correctly. To continue with your operation please disable this
configuration or contact your administrator.
What am I doing wrong?
The solution is to be found in a similar question: Why I get Internet Explorer enhanced security error message in Chrome if I call VSO API from Angularjs SPA?
Andy writes
the PAT has to be prefix[ed] by ":" before you base 64 encode it"
So the solution is:
Create a Personal Access Token
Add a colon (':') before it
Encode the new PAT (with the preceding colon) using Base 64
Et voila ! That PAT will no longer give you a 203 error.
It's mainly caused by the PAT format is incorrect.
Such as if I add colon : before the PAT, the REST API will return with 203.
adding on to #numeratus
This question took awhile for me to get correctly on powershell. https://www.opentechguides.com/how-to/article/azure/201/devops-rest-powershell.html helped me greatly and a resulting simplified powershell request to azure apis
#enter your token in pat token
$pat = "xxx"
# Create header with PAT
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($pat)"))
$header = #{authorization = "Basic $token"}
#enter your url in projects url
$projectsUrl = "https://feeds.dev.azure.com/"
$projects = Invoke-RestMethod -Uri $projectsUrl -Method Get -ContentType "application/json" -Headers $header
Related
I've been trying to access our on-prem JIRA Server (configured with plain HTTP) using PowerShell Invoke-RestMethod, but I think I'm missing something.
The authentication header is created in base64
$cred = [convert]:.ToBase64String([text.encoding]::ASCII.GetBytes("account:password"))
$headers = #{Authorization = "Basic $cred"}
Using REST, I then ask for the issue (without posting any property filter to keep the request simple while I'm learning).
Invoke-RestMethod -Uri http://jiraserver:8080/jira-software/REST/agile/1.0/issue/test-1 `
-Headers $headers -ContentType "application/json" -AllowUnencryptedAuthentication
This obviously fails, as I get back a reply containing a login form
<form action="/login.jsp"
class="aui"
id="login-form"
method="post">
I do think I remember that basic authentication is no longer supported in JIRA.
How do I use OAuth in that case instead?
When working with another task that is well within the scope of Atlassian´s PowerShell module JiraPS, I noticed a command called Invoke-JiraMethod.
It turns out that the module provides JIRA REST API access :)
So by setting up a JIRA session with the PowerShell module, I'll be able to use REST over an unencrypted connection.
I have VSTS builds that use the Powershell script to access the VSTS API, similar to that detailed in Microsoft's Documentation.
The document states:
To enable your script to use the build process OAuth token, go to the Options tab of the build definition and select Allow Scripts to Access OAuth Token.
After you've done that, your script can use to SYSTEM_ACCESSTOKEN
environment variable to access the VSTS REST API. For example:
Example:
$url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build-release/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=2.0"
Write-Host "URL: $url"
$definition = Invoke-RestMethod -Uri $url -Headers #{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
Write-Host "Definition = $($definition | ConvertTo-Json -Depth 1000)"
As detailed in Microsofts Documentation, I'm sure you used to go to Build > Options and click 'Allow Scripts to Access OAuth Token', but it is no longer there (see pic below).
When I try a build I get the following (which doesn't happen for my old builds):
Invoke-RestMethod :
{"$id":"1","innerException":null,"message":"TF400813: The user '' is
not authorized to access this
In addition, when I clone a build (which worked nicely when I did it 3 months ago), the property is set to false (it's set to true on the original).
UPDATE: If I export from VSTS, change that property and import again, it works, but I really need a solution without this sort of manual intervention.
How should this be done now please?
It is available in the agent phase now
This REST request works when I load it directly in a browser in which I'm simultaneously logged into the Kentico 8.2 admin site:
https://www.example.com/rest/CMS.SettingsKey
Now, I need to return the same results using PowerShell 5. I tried various versions of the following:
$url = "https://www.example.com/rest/CMS.SettingsKey"
$httpMethod = "Get"
$credentialsBytes = [System.Text.Encoding]::UTF8.GetBytes("username:password")
$credentialsEncoded = [System.Convert]::ToBase64String($credentialsBytes)
$headers = #{}
$headers.Add("Authorization", "Basic $($credentialsEncoded)")
$settings = (Invoke-RestMethod -Uri $url -Method $httpMethod -headers $headers)
Write-Host $settings
Note that "username" and "password" are the same credentials used to log into the admin site (when the REST request is working in the browser), and the user is a global admin.
The PS snippet gives me a 403 Forbidden error. I followed this page and this page, but I can't get it to work. What am I doing wrong?
EDIT:
I enabled the REST service, but now I'm getting a 401 Unauthorized error. Again, the user is a global admin. I get the feeling the headers aren't being included in the request (or that there is a problem with the headers), because the same request works (from PowerShell) if I generate a hash and use hash parameter authentication instead of basic authentication. I tried using Fiddler a bit as suggested in comments, but I'm new to it, and I don't have time to dive in too deep right now.
Just tested it using the latest hotfix versions (9.0.32 & 8.2.48) and it works just fine.
Make sure REST is enabled for the specific site (not only the global setting)
Make sure you have <modules runAllManagedModulesForAllRequests="true"> in your web.config as described here.
I generated an server key for Chrome Store API in the Developer Dashboard. I would like to publish a .zip file containing my extension programmatically. The instructions in https://developer.chrome.com/webstore/using_webstore_api show OAuth, Bearer token authentication. How can I use the server key instead?
Things I tried: header "X-ApiKey" = "$apiKey", adding ?key=$apiKey, etc.
In all cases
{"error":{"errors":[{"domain":"global","reason":"required","message":"Login
Required","locationType":"header","location":"Authorization"}],"code":401,"message":"Login
Required"}}
For this example I have been using Powershell Invoke-RestMethod
$headers = #{
"X-ApiKey" = $apiKey
"X-Goog-Api-Version" = "2"
}
$endpoint = "https://www.googleapis.com/upload/chromewebstore/v1.1/items/$appId/?key=$apiKey"
Write-Host $endpoint
$response = Invoke-RestMethod $endpoint -Method Put -InFile $filePath -Headers $headers
More docs, and no clues - https://developer.chrome.com/webstore/api_index
You can't. API keys are only used to access public data. To use the Chrome Store API, you must authenticate as the user who you wish to publish the app as and, thus, you must supply an OAuth token. Check out the OAuth 2.0 Playground for an example of how to get an OAuth token.
I am attempting to update the UPN of an Azure AD user (loaded with Azure AD Connect) in a federated domain via MS Graph leveraging the .Net ADAL library in Powershell. I am reasonably certain that I have everything configured correctly within Azure and in the PS, because if I issue a command to update the usageLocation attribute, it works (clipped for brevity):
$UPN="user#mytenant.edu"
$Body=#{UsageLocation="JP"} | ConvertTo-JSON
$Result=Invoke-RestMethod -Method PATCH -Uri "https://graph.microsoft.com/v1.0/users/${UPN}" -Headers #{Authorization=$authenticationResult.CreateAuthorizationHeader()} -ContentType "application/json" -Body $Body
$user=Invoke-RestMethod -Method GET -Uri "https://graph.microsoft.com/v1.0/users/${UPN}?`$select=usageLocation" -Headers #{Authorization=$authenticationResult.CreateAuthorizationHeader()} -ContentType "application/json"
$user.usageLocation
JP
But, if I attempt to update the UPN to a non-federated domain (so I do not run afoul of the issue described in http://blogs.perficient.com/microsoft/2013/03/changing-upn-for-office-365-account-between-two-sso-domains/), I get back an Internal Server Error (500):
$UPN="user#mytenant.edu"
$Body=#{userPrincipalName="user#tenant.onmicrosoft.com"} | ConvertTo-JSON
$Result=Invoke-RestMethod -Method PATCH -Uri "https://graph.microsoft.com/v1.0/users/${UPN}" -Headers #{Authorization=$authenticationResult.CreateAuthorizationHeader()} -ContentType "application/json" -Body $Body
Invoke-RestMethod : The remote server returned an error: (500) Internal Server Error.
I've tried many different variations, including retrieving the Azure AD GUID and using that rather than UPN in the PATCH command and using the older Azure AD Graph (which returns the same 500 error). I can make the change using O365 Powershell commands:
Set-MsolUserPrincipalName -UserPrincipalName $UPN -NewUserPrincipalName $newUPN
but I can't seem to make it work via MS Graph. The docs for graph imply that UPN can be updated like other attributes (c.v. http://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/user_update, for example). I'm wondering though if because UPN is a key, maybe that makes update not work? I also don't think this is a permission issue, those usually throw "Insufficient privileges to complete the operation." which is not what I'm seeing.
Thank you!
UPDATE1: Here's everything I can fish out of the Error object from a re-attempt this morning :
{
"error": {
"code": "Service_InternalServerError",
"message": "Encountered an internal server error.",
"innerError": {
"request-id": "cbb08d3c-1143-4d0b-8722-5230b00bd00f",
"date": "2016-02-15T16:48:15"
}
}
}
I took a look at the trace, and I will file a bug on our side for the 500 error (we can certainly do better here). Based on the trace, if you are updating a user by renaming them out of a federated domain into a cloud managed domain, you MUST provide/set a password as part of the request (using passwordProfile complex type). That is why the request is failing according to the logs. Please let us know if this solves your issue.