Re: How to validate user credentials for a user account after ClientLogin is sunset?

[Bartosz Ferenc]

Hi,
It's works. Another instace /singleton AdwordsUser uses auth.ini in my test
code. My test object doesn't use it but had access to this variable. THX

2016-09-28 17:03 GMT+02:00 'Josh Radcliff (AdWords API Team)' via AdWords
API Forum <adwords-api@googlegroups.com>:

> Hi,
>
> In step 3, are you clearing the client customer ID? If not, then that
> attribute may be left over from your previous request or set via the 
> clientCustomerId
> in your auth.ini
> <https://github.com/googleads/googleads-php-lib/blob/master/src/Google/Api/Ads/AdWords/auth.ini#L14>
>  file,
> and the access token probably doesn't have access to that customer ID.
>
> Thanks,
> Josh, AdWords API Team
>
>
> On Wednesday, September 28, 2016 at 9:20:54 AM UTC-4, Bartosz Ferenc wrote:
>>
>> 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 (A

Re: How to validate user credentials for a user account after ClientLogin is sunset?

[Bartosz Ferenc]

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 
> 
>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 
>
> 
>  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.