In recognition of the Presidents Day holiday, our Support office will be open with limited availability on Monday 02/18 from 10:00 am - 6:00 pm ET. Check out our Help Center for all the ways to get in touch with us and get help.
We have a batch job that currently uses the version 2 api to push bulk updates from a main frame to constant contact. Due to the TLS 1.2 requirement, we were planning to rewrite the app to use the version 3 api, but the API does not appear to have an authentication route for automated system, the two listed pathes require user interaction for the authentication to occur.
Is there another authentication option or if not another mechanism to provide automated feeds.
Our v2 API required user interaction for authentication as well. The difference is the v2 API did not expire for a long time where as the v3 API expires in about 2 hours. However; once you do the initial user interaction (which was required in v2) then any additional refresh can happen automatically if you write your oAuth code correctly.
The part of oAuth in both v2 and v3 API that needs to have user interaction is when the user logs in to their Constant Contact account and clicks allow. After this everything else can be automated.
Interesting, it appears to never expires because we have the token saved as a configuration variable and just send it in the request. It's never expired in 4 years than.
The Access Token with our v2 API technically expires and it can be set to expire quicker, but the default is 315359999 seconds which is about 10 years. You can view this in our documentation here. Search for "Access Token Response" and it is in that section.
When we released our v3 we decided that wasn't the most secure of expiration timeouts so we changed it to expire quicker. However; once you get the Access Token while you will not want to hard code that anymore you can still write your code to refresh that automatically without any further user interaction.
Still not a good answer. I think your assuming the job is continuously running, and can perform a refresh. However it is a scheduled job that executes once at 2AM and takes about 25 seconds. It's not executing for the rest of the time.
So how would it get the initial token, without user interaction?
The initial token requires user interaction; this was also the case with our v2 API. There was no way you could get an Access Token with our v2 API that did not involve the owner of the Constant Contact account interacting and granting permission to your application.
When using the v3 API this initial token will also require user interaction, but that is the only time that it will be required. After you have the initial token you can store that data just like when using the v2 API. However; after two hours have passed you will be prompted that the token has expired. In that instance you will then need to go through the refresh portion of the v3 oAuth. The refresh portion does not require interaction from the user.
When doing the refresh part of oAuth you will be provided with a new Access Token which you will replace the original token with and it will last for two hours. After which you will need to go through the refresh portion again. Please keep in mind the refresh portion can all be coded to happen automatically so that it does not require any interaction from the developer or the user.
You can see both a cURL and PHP example of the full oAuth process here.
I have been trying to figure out something similar for about a day.
In my case I want to integrate newsletter subscriptions (newsletters from me) for users of my application where they can manage subscriptions (multiple mailing lists) from my app settings, my app would then take their preferences and manage that on my CTCT account via the API. The problem is that there is no room for OAuth for the users, it doesn't make any sense either.
With v3 it is obvious that v2 allowed for two use cases. In v2 you could generate access token and leave that in the system settings and have access to the one account you wanted to manage. This probably wasn't how the API was intended to use, but this hack worked.
The second use case, which is the only one that v3 allows, is that you use an app through which you can interact with you CTCT account. This is perfect for most scenarios where there is a personal interaction, like setting up a plugin for Wordpress. This is lacking for automated systems like mines where I need to setup some initial button in administration to click to trigger the OAuth flow to get the needed credential (not to mention building the entire OAuth flow and management just for this) instead of simply calling the API with my username & password for authentication.
That is my take on this. Please correct me if I'm wrong and/or missed something.
Your take on how the oAuth worked in v2 API is correct. We did not intend people to use our API Tester page to generate an Access Token and skip writing an oAuth flow, but that is what happened.
In a perfect development world (we all know the world is not perfect) every integration will have its own oAuth flow built in. There are a few reasons to do this, but one of the most important reasons is security. Security for both the developer and the end-user.
It seems there might be some confusion on which form of oAuth to set up as well: client-side or server-side. We will look in to making our documentation better on what each one is used for going forward. About 95% to 98% of the time an integration is going to be using server-side oAuth.
In the scenario of your newsletter subscriptions I'm not positive if this is something that is installed on your computer, or on the user's computer. If it is installed on your computer then it will only ever need one Access Token and that is for your Constant Contact account. In this case I can see how oAuth may not be as useful.
Let's take the scenario of a developer making a program for hundreds or thousands of users. I will use our WordPress Plugin as an example. It is designed to be installed on the end-users computer and require that user to authenticate with their own Constant Contact account over a website. This requires server-side oAuth because the application while installed on the end-user's computer actually runs on a web server. The end-user authenticates and then the program is able to communicate between the Constant Contact account and program.
If you hard coded the Access Token such as what happened with a lot of developers using v2 then the program would only be able to talk to the single account with which the Access Token is attached.
In actuality v2 and v3 oAuth are the same with one difference and that is Access Tokens expire faster and need to be refreshed. The ability to get around oAuth was never intended and we hope developers will use this opportunity to add a bit more security in to their programs.
Thank you @Jimmy_D,
That was what I thought.
I think what would be appreciated would be addition of HTTP Basic Authentication (or something like that) so that users can access only their own account. This would be useful for scenarios where the project is only concerned about managing one (their own) account on their own platforms.
Maybe something similar to Mailgung approach, but in case of CTCT it would mainly concern managing contacts and their mailing list subscriptions.
I'll add this as a API enhancement request.
Once again thank you for your answer.