Is it possible to programmatically request business partner with access assets business owns.
Facebook business-manager-api describes best practices to work with business-manager-api. Would be very handly if our app can request partnership to client or agencies business managers programmatically.
Update
So after digging documentation, playing with Facebook Graph API and asking on official Q/A groups we came to conclusion, that at this moment Facebook API doesn't provide any endpoint to request business partnership. So we refactor our flow and now we will request access to business's ad accounts. I will accept answer as correct, cause at this moment this is the only possible solution
The Business Manager API provide a functionality to request access to assets. This is documented in the Business-to-Business Functions of the Assets section.
For example,
Business Manager may request access to an ad account or a page owned by another business manager. They must specify the roles that they want need to be able to assign in the request.
To request AGENCY access, you must provide permitted_roles in your request. You can only send request to assets to business manager that you intend to approve and that they must already know your business.
For example, a business that needs access to adaccount_id and needs to be able to assign its employees as GENERAL_USER and REPORTS_ONLY would make this POST call:
curl \
-F "adaccount_id=act_<AD_ACCOUNT_ID>" \
-F "permitted_roles=['GENERAL_USER','REPORTS_ONLY']" \
"https://graph.facebook.com/<API_VERSION>/<BUSINESS_ID>/client_ad_accounts?access_token=<ACCESS_TOKEN>"
When using this api now
curl \
-F "adaccount_id=act_<AD_ACCOUNT_ID>" \
-F "permitted_roles=['GENERAL_USER','REPORTS_ONLY']" \
"https://graph.facebook.com/<API_VERSION>/<BUSINESS_ID>/client_ad_accounts?access_token=<ACCESS_TOKEN>"
it says
"(#3) Application does not have the capability to make this API call."
you should use Business On Behalf Of instead.
Related
So I'm working on a small project. It's a REST API that will act as the back-end for a 'buy and sell' website.
At the moment I have two main resources: Users and Ads.
A user can create many ads. Every ad was created by some user.
Could someone verify that the following endpoints follow REST principles and that they make sense? If you don't think they look right please suggest an alternative.
//Users
Create a user - POST /api/users -
user details are passed as json in request body.
Get a user by id - GET /api/users/{user_id}
Get the logged in user - GET /api/users/authenticated_user -
An authentication token is passed in the request header and is used to find the user in the database.
Update the logged in user - PUT /api/users/authenticated_user -
new user details are passed in the request body. An authentication token is passed in the request header and is used to find the user in the database.
Delete the logged in user DELETE /api/users/authenticated_user -
An authentication token is passed in the request header and is used to find the user in the database.
Get an ads user - GET /api/ads/{ad_id}/user
//Ads
Get all ads - GET /api/ads
Create an ad - POST api/ads -
ad details are passed in request body and the user_id of the ad creater is got from the authentication token passed in request header. Would this endpoint make more sense to be something like: /api/users/authenticated_user/ads
Get an ad by id - GET /api/ads/{ad_id}
Update an ad - PUT api/ads/{ad_id} -
ad details are passed in request body and the user_id of the ad creater is got from the authentication token passed in request header to make sure the ad was created by him/her. Would this make more sense to be api/users/authenticated_user/ads/{ad_id}
Delete an ad - DELETE api/ads/{ad_id} -
The user_id of the ad creater is got from the authentication token passed in request header to make sure the ad was created by him/her. Would this make more sense to be api/users/authenticated_user/ads/{ad_id}
Get a users ads by id - GET /api/users/{user_id}/ads
Get logged in users ads - GET /api/users/authenticated_user/ads -
An authentication token is passed in the request header and is used to find the user in the database.
The reason for using the authentication token in some endpoints is because the client doesn't have access to the user_id of the logged in user only the authentication token.
Thankyou, would really appreciate your input.
Could someone verify that the following endpoints follow REST principles and that they make sense?
REST doesn't have "endpoints", it has resources. (Fielding, 2018)
Any identifier that is consistent with the production rules described in RFC 3986 "follows REST principles".
What "REST principles" would tell you to do is to design a web site, with interlinked hypertext documents, and web forms, and to take advantage of the standards that are shared on the web.
But what REST doesn't tell you is what pages should be on your web site, or what spelling conventions should be used for your web pages, or how to bridge the gap between the web site and the interesting business activities in your domain.
Any spelling convention you want to use for your resource identifiers is fine. The machines don't care if the spelling of the identifier matches the semantics of the resource.
Humans tend to prefer human readable identifiers - access logs and browser histories are easier to analyze when you can guess what the resource is from the identifier spelling.
Identifier families that can easily be described by URI templates make a number of mapping chores (like routing) much easier.
And of course, it's really useful if bookmarks remain stable.
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I have been experimenting with the REST API using my logged in user account's token to then make PUT requests on my user record to update some custom attributes.
In order to get to this work I had to grant my user account the manage-users role in Keycloak, prior to this I was getting forbidden responses back.
I can now make the PUT request successfully, and after logging out and logging back in I can see the updated attributes I set in my PUT request.
But I have now allowed my user to be able to manage all users in my realm, which I dont want to allow.
Instead I only want to be able to update my own account details.
I know the user can view their own profile and make changes on the Keycloak provided screens. But for certain custom attributes I want to be able to do this from the client side application they are logged in to, so using the REST API but not granting them a role that could allow them to update other users details.
Is this possible?
According to the User section Keycloak's Admin REST API, this is not possible.
One solution would be for your client app to send the update request to a backend. The backend will verify that the update request is legit (aka the JWT is verified and the update does apply to the user requesting the change).
Another solution would be to theme the User Account Service's screens to add input fields for your custom attributes, as the documentation says that:
This screen can be extended to allow the user to manage additional attributes. See the Server Developer Guide for more details.
The second option seems the more secure. I hope that helps.
This seems to be possible with the Account Management API.
Unfortunately, I didn't find any official documentation about that. However, there's an example in Keycloak that demonstrates how to do it.
I'm trying to interact with the Salesforce REST API for an organisation, and was wondering if it had any notion of Service Accounts or Application Owned Accounts. I can't find any mention of it in the documentation, but maybe they use different nomenclature.
I'd like to enable some form of domainwide delegation of authority, so users aren't faced with the pop up requesting access to their data. This is an internal app, only for this particular organisation.
No, there are not service accounts. There are 'Chatter' user licenses that are free but have reduced functionality: http://www.salesforce.com/chatter/getstarted/?d=70130000000tRG7&internal=true#admin
FAQ: http://www.salesforce.com/chatter/faq/
I'm looking for some deep down detailed information on google's use of oauth scopes
My Drive app is working, so I get the simple use of scopes. However I have the following detailed questions/issues..
I specify scopes twice. Once in my app and then also in the API
Console. What is the respective significance of these two scope
declarations?
If I remove scopes, must my user re-authorise my app, or is this
only required for adding additional scopes?
If the answer to 2, is 'I can't silently remove scopes', will the
Google libraries deal gracefully with re-authorising the user, or
will I just get 403 failures? I've read How should an application add/remove scopes to an existing grant? but the accepted answer specifically references adding scopes, whereas my question is about removing scopes.
Can different modules within my app request different scopes within
the superset specified in the API console? To explain, my app has 3
components: a chrome extension accessing Drive, a web client using
JS to access Drive and YouTube (in online mode), and a server
component which accesses Drive (in offline mode)..
Can my app. enquire what scopes it has been granted?
A general question, I'm sure I face the same dilemma as many app authors. If I increase functionality (a good thing since it attracts users), I also need to increase permissions/trust a user places in my app (a bad thing since it repels users). Are there any recommendations on how apps should best handle this conflict of interests?
List of scopes in your client code - this is what a user authorizes your app to do
When you request authorization from a user, you need to specify what you would like the user to consent to. This is what the list of scopes is used for - it controls the text the user sees when they authorize your application, and the refresh / access tokens granted by that authorization are limited to making API calls that are allowed by those scopes.
List of enabled services in the API Console - this is what your app authorizes users to do
To my knowledge there is no list of scopes specified in the API Console. There is however a list of Google services that can enabled. Enabling/disabling a service here is more about turning on/off ability to make API calls and managing quota and/or accepting terms of service related to that API, than it is authorization.
When an API call is made - you send along an access token
The access token encapsulates the user making the request, the scopes the user authorized you for, and the client ID used for the authorization (which in turn belongs to your project). At this point you need to have the service that the API call is sent to enabled on the project, and the correct scope for the API request - or you will get a 403.
When your list of required scopes changes - you should expect users to need to re-authorize
At the point you request an access token (typically by sending a refresh token) you need to be prepared for that request not to succeed. Maybe it's because you've added scopes - but maybe a user has chosen to visit https://accounts.google.com/IssuedAuthSubTokens and has revoked your applications access. I'm not sure whether if you request less scopes than was granted by the user initially will trigger this, I would experiment to test - but the point is that regardless your code needs to be able to handle this scenario. I believe the OAuth2DecoratorFromClientSecrets (from the linked question) will handle this gracefully for you but am not certain - it should be easy enough to verify.
Using the same authorization across multiple clients - suggest reading through this doc and see if it covers all of your scenarios: https://developers.google.com/accounts/docs/CrossClientAuth
To see scopes granted to an access token - use the OAuth2 API: https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=yaxxxxxxxxxxxxxxx