Hi Josh, I have a problem. 1. Customer agrees by Oauth2 on campaign management and application receives ACCESS_TOKEN and refresh_token. Everything is OK. 2. To be able to manage user account I need to know his clientcustomer_id. 3. I want to get them through CustomerService.get using customer refresh_token. 4. API returns permission_denied. 5. If i enter manually $user-> SetClientCustomerId ($client_customer_id) everything works properly.
I would like to receive via CustomerService.get client_customer_id which seems possible - the documentation shows that this method does not require client_customer_id and should be return it, using only refresh_token. Am I right? Why it did not work? W dniu poniedziałek, 17 marca 2014 17:12:41 UTC+1 użytkownik Josh Radcliff (AdWords API Team) napisał: > > Hi Chris, > > One way you could deal with the issue you described would be to go through > a small OAuth flow for account A1 at this step: > > *Someone logs into our web application and configures a new application > account B1, intended to display data for account A1* > > If the person entering in the account at that point only has access to A1, > then you could: > > 1. Take the user through the OAuth2 *Web Application *flow. He would > presumably log in at that point as a user who only has access to A1 (you > could just request the *online *access_type instead of the offline > access_type > <https://developers.google.com/accounts/docs/OAuth2WebServer#offline> > for this, since you're going to use the *access token* immediately). > 2. When your website or app gets the authorization code from the > OAuth2 flow, exchange it for an *access token*. > 3. Use the *access token* and the account ID the user entered to > perform a basic API request such as CampaignService.get > > <https://developers.google.com/adwords/api/docs/reference/v201402/CampaignService#get> > for > the account ID he entered. If that fails, then chances are the user > entered > the wrong account ID. In the example you gave, you would have an access > token for A1 but an account ID for A2, so the request would fail. > > Does that sound feasible for your use case? > > Thanks, > Josh, AdWords API Team > > On Monday, March 17, 2014 11:34:58 AM UTC-4, Chris wrote: >> >> Hi Josh, >> >> The use case is as follows: >> >> We have MCC M1 and AdWords accounts A1 and A2 >> Both A1 and A2 are already linked to M1 >> We have a web application that has the necessary information to pull data >> from accounts in M1 >> Someone logs into our web application and configures a new application >> account B1, intended to display data for account A1 >> During the configuration process, the client id for A2 is entered in error >> B1 is now pulling and displaying data for A2 >> >> It is easier to arrive at this situation when only a client id is >> required. If a user has to also provide a valid login for the corresponding >> account, then this kind of error would be less likely, as the mistake >> should be clearer e.g. in the example above, if we see the credentials for >> us...@account2.com provided in B1 then this looks like an error has been >> made >> >> On Friday, 14 March 2014 16:13:36 UTC-3, Josh Radcliff (AdWords API Team) >> wrote: >>> >>> Hi Chris, >>> >>> Put another way, is your use case as follows? >>> >>> 1. You have MCC M1 and AdWords account A1. >>> 2. A1 is linked to M1. >>> 3. Someone on your team creates AdWords account A2. >>> 4. That same person goes to the MCC UI (or uses your app) to send an >>> invitation to A2 to be linked to M1, but accidentally enters the ID for >>> A1 >>> instead. >>> >>> In this scenario, if your app then attempts to issue an API request >>> against A2 using OAuth2 credentials from M1, the API request will fail >>> because the link between M1 and A2 was never created or accepted. >>> >>> I'm not sure if that's actually the use case you described. If not, >>> could you provide some more details? >>> >>> Thanks, >>> Josh, AdWords API Team >>> >>> On Friday, March 14, 2014 11:27:30 AM UTC-4, Chris wrote: >>>> >>>> Hi Josh, >>>> >>>> Thanks for your reply! The situation I am concerned with however is >>>> where we already have clients linked to our MCC. Let's say that one of the >>>> people on our team is setting up a new account in one of applications that >>>> uses the AdWords API, and by mistake enters the client id for client X >>>> from >>>> the MCC rather than for client Y. This is still a valid account, linked to >>>> the MCC, but due to a simple mistake is not the client id that we want. If >>>> I could also validate this client id against client-specific login >>>> credentials then that would be a useful extra step for validating that we >>>> infact have the client id that we want to use. A user is less likely to >>>> enter incorrect login credentials such as u...@clientx.com for the client >>>> Y >>>> account. >>>> >>>> On Thursday, 13 March 2014 15:33:32 UTC-3, Josh Radcliff (AdWords API >>>> Team) wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> When your MCC sends out an invitation to an AdWords account (either >>>>> via the My Client Center UI or a ManagedCustomerService.mutateLink >>>>> <https://developers.google.com/adwords/api/docs/reference/v201402/ManagedCustomerService#mutateLink> >>>>> ADD >>>>> + PENDING call) the user associated with that account will still have to >>>>> either accept or refuse the invitation. Accepting the link will either be: >>>>> >>>>> 1. A manual interaction through the AdWords UI *or* >>>>> 2. Managed by your application via a >>>>> ManagedCustomerService.mutateLink >>>>> >>>>> <https://developers.google.com/adwords/api/docs/reference/v201402/ManagedCustomerService#mutateLink> >>>>> SET >>>>> + ACTIVE call >>>>> >>>>> In either case you will be able to detect when the client enters a >>>>> customer ID for which he does not have access. >>>>> >>>>> 1. If the client does not actually own the customer ID then he >>>>> won't get the invitation at all. It will either go to the owner of >>>>> the >>>>> incorrectly entered account (if it exists) or sending the invitation >>>>> will >>>>> fail. >>>>> 2. In order for your application to accept the link on the user's >>>>> behalf you will have to prompt the user for permission to manage his >>>>> AdWords account. If he entered the wrong account number then the >>>>> ManagedCustomerService.mutateLink >>>>> >>>>> <https://developers.google.com/adwords/api/docs/reference/v201402/ManagedCustomerService#mutateLink> >>>>> SET >>>>> + ACTIVE call will fail because the OAuth2 access token will be for an >>>>> account that does not have access to the incorrectly entered customer >>>>> ID. >>>>> >>>>> Another possible flow would be that you collect the customer ID and go >>>>> through the OAuth2 flow at one point, and then at some later point in >>>>> time >>>>> go through the MCC invitation process. If that's your use case then at >>>>> the >>>>> point where you collect the OAuth2 token you could issue a simple request >>>>> such as a CustomerService.get >>>>> <https://developers.google.com/adwords/api/docs/reference/v201402/CustomerService#get> >>>>> >>>>> where you specify the clientCustomerId and use the OAuth2 credentials >>>>> from >>>>> the user. If the user entered the wrong customer ID then that request >>>>> will >>>>> fail with a permission error. >>>>> >>>>> Cheers, >>>>> Josh, AdWords API Team >>>>> >>>>> On Thursday, March 13, 2014 10:57:23 AM UTC-4, Chris wrote: >>>>>> >>>>>> Hi Guys, >>>>>> >>>>>> I'm looking at updating our applications to using OAuth2.0 >>>>>> authentication, and it certainly seems that it would be easiest to have >>>>>> all >>>>>> account linked under one master MCC, as described here >>>>>> https://developers.google.com/adwords/api/docs/guides/clientlogin-to-oauth2-single-mcc >>>>>> >>>>>> However, my concern with this approach, is that I do expect users to >>>>>> occasionally input the id for the wrong account by mistake. The >>>>>> consequences of this could be less than desirable. Currently we use >>>>>> ClientLogin for authentication, and a user is required to input the >>>>>> client >>>>>> id, username and password. If I could still make use of this >>>>>> information, >>>>>> and validate that the login credentials provided are valid for the >>>>>> account >>>>>> id specified, then that would go a long way to alleviating my concerns >>>>>> (it >>>>>> can be easier to see from an email address what account it is associated >>>>>> with, compared to a numeric id). >>>>>> >>>>>> So, my question is - is there is still a way that I can validate >>>>>> login credentials against an account id? >>>>>> >>>>>> Or, am I in fact misunderstanding something in relation to OAuth2.0 >>>>>> authentication, since this is the first time I'm really looking into it? >>>>>> >>>>>> Any thoughts or comments are much appreciated. >>>>>> >>>>>> Chris >>>>>> >>>>> -- -- =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ Also find us on our blog and Google+: https://googleadsdeveloper.blogspot.com/ https://plus.google.com/+GoogleAdsDevelopers/posts =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~ You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To post to this group, send email to adwords-api@googlegroups.com To unsubscribe from this group, send email to adwords-api+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/adwords-api?hl=en --- You received this message because you are subscribed to the Google Groups "AdWords API Forum" group. To unsubscribe from this group and stop receiving emails from it, send an email to adwords-api+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/adwords-api. To view this discussion on the web visit https://groups.google.com/d/msgid/adwords-api/940bec0b-0b31-434e-a74d-3b5efadfc089%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
