Constant Contact wants to help you succeed! We’re celebrating our professional service programs on the Constant Contact Community this month and you have a chance to try one of the services for free! Learn more.
I recently set up PHP contact form on a website (for a friend/freelance client) that used the CtCt v2 API to handle a newsletter-opt-in checkbox in the form. All was working fine, until this client migrated his site to a new host running PHP 7.1.25 (was previous 5.x, I suppose). There was some issue with the guzzle dependency in the provided CtCt PHP SDK, and I found a post in this form where a developer pretty clearly stated that on PHP 7+, you really should be using the new v3 API.
Now that I've spend some looking at the v3 docs, though, I'm confused about Oauth. Both the client and server flows explained in the docs seem to assume a CC customer manually end user providing authentication as part of the process — but this is a very basic integration where the code living on the CC customer's own web server needs to access that owner's list data and create a contact in response to someone else's submission of a form—the site owner is not present in the transaction to authenticate themselves. Is this a case the v3 API can handle?
Most likely scenario is I'm just looking at this wrong and need some explanation, I realize...
Solved! Go to Solution.
The post I referred to was https://community.constantcontact.com/t5/Developer-Support-ask-questions/PHP-5-4-v-7-2/m-p/307766... and I noticed at the end it does say that the alpha version of the SDK did seem to work for the person who posted, so I guess I'll try that even though the thread is a bit over a year old. I'd still love to hear back on this just to help me understand Oauth better.
Thanks for reaching out to Constant Contact's API Support.
The v2 API also required the user's input to authorize. This seems to be a common misperception between the two APIs and I believe the reason for this is with our v2 API you could generate an Access Token that lasted for a very long time. However; to generate the Access Token you still needed the user's Constant Contact username/password which is the exact same requirement in our v3 oAuth.
The only difference between oAuth in v2 and v3 is that our v3 Access Tokens expire after 24 hours and has to be refreshed. This does not require any extra user input. If you have the Access Token already then you can refresh it automatically.
I have to ask how did you get an Access Token for your v2 API sign-up form without the Constant Contact username and password?
Oh, I did get access with CC credentials, just through the IO-docs page (https://constantcontact.mashery.com/io-docs) and not an Oauth flow. I think I get it now, thanks.
Using the I/O-docs page is still technically input from the user of the account; in this case you did the interaction and then probably hard coded the Access Token.
To be more secure we have lowered the expiration time of the Access Tokens from 10 years (v2 timeout) to 24 hours (v3 timeout). If you write your program correctly you can still do the customer input yourself and generate an Access Token which will then automatically refresh every 24 hours using the refresh portion of oAuth. Instead of harding coding these now you will just need to write the code to have them changed out.
If you need assistance with this feel free to reach out to us at email@example.com.
We have started implementation of the v3 api and I would like to know how you get a new token everyday without having to use the I/O-docs pages. I have the username, password, api key, and secret but I don't see how to use them to get a new token programmatically. We are using php 5.4 and I have been able to used the I/O-docs generated token to retrieve the contact_list data but I cannot seem to get it to pass back a new token.
Regardless of the version of the API you are using you will want to use the oAuth flow to generate an Access Token. It sounds like you are using the v3 API if your token is expiring after a day. If this is the case you will want to make sure you include the refresh portion of the oAuth flow.
Each post like this seems to end the same way, with support pointing folks to the server flow docs page. Unfortunately, I've read it several times and still don't see how a refresh token solves the problem of server to server authentication without requiring user input. As I understand the process of refreshing the token as part of the server flow, you'd POST to the CC auth endpoint with the refresh token so you can obtain new access and refresh tokens. The problem is that in a server to server scenario the server would need to maintain the last refresh token that was obtained. That's not very realistic, partly because you could have multiple requests to an API trying to make this same auth request, and also ruins the ability to remain stateless.
I hope I'm missing something, because it would be a shame if CC isn't providing a method of server to server authentication via the new v3 API. It just seems like both auth methods assume a user is making the request instead of the scenario where another API is making the request. If the latter is not possible, I hope a support rep will confirm that and have it included in the documentation to prevent confusion.