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 am setting up a Wordpress plugin which will enable end users to sign up to one of their Constant Contact lists. I am following these instructions here about oauth:
The problem I am having is that the redirect URI can only be a single URL, but I need it to go the customers Wordpress website. So this isn't going to work. I was hoping I could pass an additional query string paramter so I could then do a 2nd redirect from my website back to their Wordpress website, but I can't pass in any additional parameters.
How do I go about solving this issue? Is the solution with like a SSO as detailed here: https://developer.constantcontact.com/docs/account-management/sso.html it says: Approved Constant Contact technology partners selling Toolkit can integrate with Constant Contact's Single Sign On how do I go about becoming a technology partner? If this is what I need to do?
Your help is much appreciated!
Solved! Go to Solution.
The best solution to this issue involves having a very minimal hosted page under your control that can be used as the redirect, which would then pass the request back to wordpress. This can be done by taking advantage of OAuth 2.0 allowing query parameters to be freely appended to the redirect URI. So for example, you can set up your redirect URI as http://www.google.com and then send http://www.google.com?redirect=yahoo.com with the actual authorization request. This process would allow the page you control to read the "redirect" parameter and simply forward the request along, including any relevant OAuth parameters. It is also very important to mention that this specific process only works with the Server flow rather than the Client flow.
To give a bit of clarity on the two flows, the client flow is created for implementations such as a mobile app where you need to capture the token from a browser object and store it locally. The client flow accomplishes this by appending the token as a URL fragment, which cannot be passed along in the scenario I described above. The server flow is better suited to applications such as a wordpress plugin due to the dynamic URL.
Hopefully this provides some clarity, but please let me know if there's any questions!
Thanks so much Elijah, I am sure I can get this working now. I was on the right track but using the wrong protocal like you said.
Thanks once again,
I found this thread searching for the same thing. In our case, our app is multi-tenant, so each account is scoped using a subdomain (like basecamp and slack).
I was happy to read your response and see that I could use url parameters to differentiate which account was making the call, but then I saw a message explicitly stating that this is not possible:
Would you mind double checking as to the current status as far as the ability to use url parameters? I'm hoping this message isn't true / outdated?
This information means that URL Query Parameters are not allowed within your registered redirect URI. You can use them in practice, they just can't be stored as a part of your registered redirect URI within Mashery.
Tier II API Support Engineer
Hi API support team,
Can you confirm if this method can still work with the v3 API? I found the refresh token will be invalidated/revoked once another refresh token is generated (say I have two sites and they are authenticated in the same app with the same CTCT account).
Thus I feel this "having a very minimal hosted page under your control that can be used as the redirect" method cannot work with v3 API anymore. Can you clarify this for me? Thanks!
This method can still work. It sounds like you have two different locations that a user can authorize. If that is the case are both locations for the exact same application or do they do different things? If they are for the exact same application then I ask why can the user authorize in two different places? If the applications do different things then I suggest to add a second API Key for your second application that way the different authorizations do not interfere with each other.
> If they are for the exact same application then I ask why can the user authorize in two different places?
Yeah because it's a WordPress plugin so a user can install it on multiple sites with just one account.
From the answer of this approach:
> The best solution to this issue involves having a very minimal hosted page under your control that can be used as the redirect, which would then pass the request back to wordpress.
In this scenario, do you mean the user should still pass their own API keys instead of just using ours (we registered an app for this minimal hosted page)? If so, then it will work like:
1. We provide this minimal hosted page URL to our users.
2. Users register their application with our URL as the return URI.
3. Users pass their API keys to our minimal hosted page (for authentication) and get redirected to their website.
Can you clarify this a bit? Thanks!
Got it! Thanks! I was able to get our app set up using a generic redirect URL in the constant contact API settings, and then passed in a subdomain parameter to properly redirect the user when they authorize.
We never recommend to have your customers get their own API Key. In this scenario you can have multiple Access Tokens to the same Constant Contact account with the v3 API. I just tested this to verify it works. Please keep in mind that an Access Token expires after 24 hours so it will have to be refreshed. However; if you have written a complete oAuth flow then each individual install of your application should be just fine as it will authenticate and refresh correctly as needed.