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