The Community is hosting an End of Summer sweepstakes! Participants must complete tasks to earn tickets that will enter them with a chance to win a free year of Constant Contact and other great prizes!*
*No Purchase Necessary. For Official Rules, visit here. Constant Contact’s End of Summer 2020 Sweepstakes ends on October, 20, 2020 at 11:50 PM EST.
Here are the significant changes and/or defect corrections that were made available in the 3/30/2012 Constant Contact API Release:
User with locked account is able to authenticate via OAuth
Previously a user whose account had been locked was able to authenticate and access protected resources via an OAuth authentication flow. This represented a security hole. The behaviour has been changed to ensure that a locked user is not allowed to login via OAuth.
GET on image list occasionally returns 406 error
Calls to the Library API to GET an image list (of the form /library/folders/<folderID>/images) were intermittently returning a 406 error when no AcceptHeader was added to the call. The correct behavior is to return 404 if any header other than ATOM+XML is sent. This includes the case of an empty header (which will now correctly return 404).
OAuth 1.0a deny access leaves user stuck on the deny access page
If a user clicks the 'Deny Access' button in an OAuth 1.0a authentication flow, they are directed to an error page. This page has several problems. First, there is a typo in the error message. Second, the instructions in the error message tell the user to close the window to return to their application. However, closing the window does nothing. We have changed the 'deny access' flow to append a 'oauth_error=user_denied_access' parameter and value to the callback URL. Programmers can now check the URL parameters in their callback handler - if the 'oauth_error' parameter is found, the user has denied access and the programmer can act accordingly.