Note: Even if we were to use properties_file with a variable to select
different files for each account, that means we also still have to have
every single account's login data hardcoded on a properties file on the
system, and we would like to avoid this if at all possible.
On Tuesday, August 14, 2012 1:09:00 PM UTC-7, PerlDeveloper wrote:
>
> Hi,
>
> Currently working on upgrading our Perl Client Library from 2.5.4 to
> 2.7.0. Because the program we use to access the API must be able to access
> individual accounts, we do not currently use an adwords.properties file to
> supply parameters to the new client as the parameters are supplied by the
> user. For example:
>
> my $client = Google::Ads::AdWords::Client->new({
> email => $email,
> password => $password,
> client_id => $clientId,
> developer_token => $developerToken,
> user_agent => $useragent,
> version => "v201109"
> });
>
> However, in updating to v201206, we're noticing that this type of setup
> results in the following error being produced:
> Couldn't find an authorization handler properly setup at
> ***/Google/Ads/Common/HTTPTransport.pm line 47.
>
> Creating an adwords.properties file seems to remedy the situation (even if
> only email, password, useragent, and developerToken are supplied in the
> file), but we would like to retain the ability to select which individual
> account to access when the user calls the function. I've noticed that the
> field names are slightly different in the properties file (developer_token
> vs. developerToken), but using camelHump notation doesn't seem to improve
> the situation. Does the Client Library no longer support providing
> parameters for new Clients outside of a properties file?
>
On Tuesday, August 14, 2012 1:09:00 PM UTC-7, PerlDeveloper wrote:
>
> Hi,
>
> Currently working on upgrading our Perl Client Library from 2.5.4 to
> 2.7.0. Because the program we use to access the API must be able to access
> individual accounts, we do not currently use an adwords.properties file to
> supply parameters to the new client as the parameters are supplied by the
> user. For example:
>
> my $client = Google::Ads::AdWords::Client->new({
> email => $email,
> password => $password,
> client_id => $clientId,
> developer_token => $developerToken,
> user_agent => $useragent,
> version => "v201109"
> });
>
> However, in updating to v201206, we're noticing that this type of setup
> results in the following error being produced:
> Couldn't find an authorization handler properly setup at
> ***/Google/Ads/Common/HTTPTransport.pm line 47.
>
> Creating an adwords.properties file seems to remedy the situation (even if
> only email, password, useragent, and developerToken are supplied in the
> file), but we would like to retain the ability to select which individual
> account to access when the user calls the function. I've noticed that the
> field names are slightly different in the properties file (developer_token
> vs. developerToken), but using camelHump notation doesn't seem to improve
> the situation. Does the Client Library no longer support providing
> parameters for new Clients outside of a properties file?
>
On Tuesday, August 14, 2012 1:09:00 PM UTC-7, PerlDeveloper wrote:
>
> Hi,
>
> Currently working on upgrading our Perl Client Library from 2.5.4 to
> 2.7.0. Because the program we use to access the API must be able to access
> individual accounts, we do not currently use an adwords.properties file to
> supply parameters to the new client as the parameters are supplied by the
> user. For example:
>
> my $client = Google::Ads::AdWords::Client->new({
> email => $email,
> password => $password,
> client_id => $clientId,
> developer_token => $developerToken,
> user_agent => $useragent,
> version => "v201109"
> });
>
> However, in updating to v201206, we're noticing that this type of setup
> results in the following error being produced:
> Couldn't find an authorization handler properly setup at
> ***/Google/Ads/Common/HTTPTransport.pm line 47.
>
> Creating an adwords.properties file seems to remedy the situation (even if
> only email, password, useragent, and developerToken are supplied in the
> file), but we would like to retain the ability to select which individual
> account to access when the user calls the function. I've noticed that the
> field names are slightly different in the properties file (developer_token
> vs. developerToken), but using camelHump notation doesn't seem to improve
> the situation. Does the Client Library no longer support providing
> parameters for new Clients outside of a properties file?
>
On Tuesday, August 14, 2012 1:09:00 PM UTC-7, PerlDeveloper wrote:
>
> Hi,
>
> Currently working on upgrading our Perl Client Library from 2.5.4 to
> 2.7.0. Because the program we use to access the API must be able to access
> individual accounts, we do not currently use an adwords.properties file to
> supply parameters to the new client as the parameters are supplied by the
> user. For example:
>
> my $client = Google::Ads::AdWords::Client->new({
> email => $email,
> password => $password,
> client_id => $clientId,
> developer_token => $developerToken,
> user_agent => $useragent,
> version => "v201109"
> });
>
> However, in updating to v201206, we're noticing that this type of setup
> results in the following error being produced:
> Couldn't find an authorization handler properly setup at
> ***/Google/Ads/Common/HTTPTransport.pm line 47.
>
> Creating an adwords.properties file seems to remedy the situation (even if
> only email, password, useragent, and developerToken are supplied in the
> file), but we would like to retain the ability to select which individual
> account to access when the user calls the function. I've noticed that the
> field names are slightly different in the properties file (developer_token
> vs. developerToken), but using camelHump notation doesn't seem to improve
> the situation. Does the Client Library no longer support providing
> parameters for new Clients outside of a properties file?
>
--
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and discussion group:
http://adwordsapi.blogspot.com
http://groups.google.com/group/adwords-api
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
You received this message because you are subscribed to the Google
Groups "AdWords API Forum" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/adwords-api?hl=en
