I am trying to figure out what is needed so that my application is able to make a pull request on behalf of my user.
I have an app registration, for this app registration I am requesting the following API permission:
https://app.vssps.visualstudio.com/user_impersonation
Once the user accesses my REST API with a proper bearer token, I need to obtain the on-behalf token so that I may contact the Azure Devops APIs.
Question is what scopes do I need to request for the on-behalf-of token so that I may create pull requests as my authenticated user?
The git repo to which I'm trying to create the pull request is hosted on o365exchange.visualstudio.com.
to create pull request on Azure DevOps Serivces side, you could call the rest api: POST https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version=6.0
You could find the needed scope under the doc:
You could find the corresponding scope details in the doc:
When you register your app, you could choose it here:
I hope this could do some help. Thanks.
Related
Consider this scenario: I have an integration API that communicates with Clio. There are several clients (unique Clio accounts) each with different users that will integrate with the API aka the Clio Application.
I want to use the Clio webhooks but should I create a new webhook for each authorised user or can I have one per client? The Webhook is created using a user's access token and is therefore tied to the access token. However, other users within the same Clio account with authorisation to the same event will trigger all the webhooks?
Can I register 1 wehbook per client or is it per user?
As I understand, you should use one Clio API token for each Clio client and you should create webhooks on events for each model, not for each user. For example, if you wanted to get a webhook request to your web service for each time a user adds an activity, you would set up the webhook on the activity update event, once. Each time an activity is updated, Clio would make a webhook call to your service for that client. Then each user's interface for that client would check the central repository for that update.
TL;DR What access rights do I need to have to be able to use the notification API to create a subscription on behalf of a user?
I'm trying to subscribe a user to a new DevOps work item I'm creating in a PowerAutomate flow. But, when the flow tries to do that, I get an unauthorized response.
https://learn.microsoft.com/en-us/rest/api/azure/devops/notification/subscriptions/create?view=azure-devops-rest-5.1#definitions
Example of step in PowerAutomate
I need to adjust the VSTS permissions for API level POST requests. So that users should not be able to get any response or result by a POST request. But still GET requests should be worked. So how can I adjust the authorization level only for REST API POST requests?
To give users who just have permissions to request GET REST API (not POST), you just need provider PAT with read permissions for related scopes.
I am developing a rather simple application that retrieves files from SharePoint using the REST Office 365 API. This is a batch job running in the background with no user interface so the following simple 2-step flow is what I'm doing:
(1) Requesting an Access Token from Azure AD (supplying client ID, client secret, resource, and grant_type=client_credentials)
(2) Invoke the SharePoint API (https://{base url}/_api/v1.0/Files) using the "Authorization: Bearer " as a request header .
That process seems pretty straightforward and sounds simple but I keep getting the following error:
401 Unauthorized
x-ms-diagnostics: 3001000;reason="There has been an error authenticating the request.";category="invalid_client"
Any idea what the problem is and how this can be resolved ? I have been stuck on this for days now. I would REALLY appreciate somebody's help with this. Thanks.
SharePoint Online doesn't yet support clients accessing it using app-only tokens (resulting from client credential OAuth2 flow). It only supports delegated token aka user+app tokens (resulting from authorization code OAuth2 flow).
So, if you wish to write a client application (web app or native client app) that accesses SharePoint online - it can only be on behalf of a user, and it must involve interactive authentication of the user - after the user authenticates - they will be shown a consent page where they need to consent to your application accessing the O365 API on their behalf.
Only Mail/Calendar/Contacts APIs (Exchange Online) support clients accessing them using app-only tokens - and they have turned on this support very recently. Read about client credential flow tokens with Exchange Online APIs here: http://blogs.technet.com/b/ad/archive/2015/02/04/using-azure-ad-to-build-daemon-applications-that-call-office-365-apis.aspx, http://blogs.msdn.com/b/exchangedev/archive/2015/01/22/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
Hope this helps.
ps: OAuth2 client credential flow doesn't issue a refresh token
You will need an access token for the specific resource you are trying to access - in this case your sharepoint site for the Office365 REST Apis.
A good read on this can be found here: https://msdn.microsoft.com/en-us/library/azure/dn645538.aspx
Assuming your {base_url} is a sharepoint site, i.e., 'https://[site_name]-my.sharepoint.com
You can either:
(1) Initially get the access and refresh tokens using your client credentials plus a resource = {base url}
or
(2) Once you have the access and refresh token from the Azure AD resource, make a refresh_token call using:
client_id
client_secret
grant_type = 'refresh_token'
resource = {base_url}
refresh_token = [refresh token received from Azure AD
generate token response]
In this case you'll have 2 access tokens:
one that can be used for Azure AD requests
one that can be used for Office365 REST Api requests.
We could not/have not found a way to have a single access token be 'valid' for more than 1 resource.
Hope this helps!
I'm trying to make a call to the new Office 365 File REST APIs. (As explained here).
I'm using Postman rest client to send the request.
I have registered my application in Azure AD and given it full permissions to 'Office 365 SharePoint Online'.
I can successfully get an authorization token using the clientId generated in Azure AD.
However when I attempt to list files, using the access token I get an error.
------------------
RESOURCE HTTP GET:
------------------
URL: https://<OUR_DOMAIN>-my.sharepoint.com/personal/<user_domain>/_api/Files
HEADER: Authorization: Bearer <access token>
Response:
3001000;reason="There has been an error authenticating the request.";category="invalid_client"
What can cause this issue?
Not sure what steps you've tried to use to resolve this, so it's hard to help you out here. I've just finished writing up more detailed instructions on the steps to register an app to call OneDrive for Business. It's long and complicated right now, but we're working to make things better in the future.
You can check out the details of how to do auth here: https://dev.onedrive.com/auth/aad_oauth.htm
Make sure you aren't asking for too many permissions, since that will require your app to be authenticated by an admin instead of the end user. For most apps, you can just use the "My files" permission scopes which can be accepted by the user of your app directly.
If you post more information about what calls you're making, responses, and app configuration in AAD I might be able to help more.
You may have been using different resources.
Check whether the resource which you have used for getting access token is same as which you are requesting for getting files.
for example :
If the resource which you have mentioned while requesting access token be :: "https://tenant-my.sharepoint.com/"
Then you need to make request on the same resource for accessing files :: "https://tenant-my.sharepoint.com/_api/v2.0/drive/root/children"
The above request give list of root children.
tenant --> domain name which was registered to your organisation.
Follow this documentation for further accessing the api