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.

GETs worked yesterday, 401 unauthorized today

Highlighted
Occasional Participant

GETs worked yesterday, 401 unauthorized today

No change to the id/pw/apikey being used.  I can log into the CC website and CC dev website, but my GETs are failing.


What have I done to anger the Gods?


  --Lars Greninger   lars.greninger@gmail.com

Lars Greninger


Hero Arts development

3 REPLIES 3
Highlighted
Occasional Participant

must use basic authentication

The digest authentication is no longer supported through Constant Contact API, and all API calls must be made using the basic authentication over HTTPS.


Please refer to the instructions on how to convert your code from using digest authentication to basic authentication.

Highlighted
Occasional Participant

GETs are fine now, POST still fails

I've switched both over to BASIC_AUTH (these are php apps).  GETing a contact and the GET of the Lists in AddAContact.php work fine.  When I execute the curl_exec() for the POST I get back a NULL  The tmp/ccsub.log log just says


2009-08-03 08:35:19 Error attempting to connect via curl to https://api.constantcontact.com/ws/customers/heroarts/contacts

 


Packet capture is not much use with SSL.


Here is the code that sets up and executes the POST:


  $session = curl_init($request);

  // Set up Digest authentication - username and password.

  $userNamePassword = CC_APIKEY . "%" . CC_USERNAME . ":" . CC_PASSWORD;

  curl_setopt($session, CURLOPT_HTTPAUTH, CURLAUTH_BASIC);

  curl_setopt($session, CURLOPT_USERPWD, $userNamePassword);

  curl_setopt($session, CURLOPT_SSL_VERIFYPEER, false);

  curl_setopt($session, CURLOPT_SSL_VERIFYHOST, 0);

  // curl_setopt($session, CURLOPT_CAINFO,"/var/www/html/BuiltinObjectToken-EquifaxSecureCA.crt");

  curl_setopt($session, CURLOPT_FOLLOWLOCATION, 1);

  curl_setopt($session, CURLOPT_POST, 1);

  curl_setopt($session, CURLOPT_POSTFIELDS, $entry);

  curl_setopt($session, CURLOPT_HTTPHEADER, array("Content-Type:application/atom+xml"));

  // Do not return headers

  curl_setopt($session, CURLOPT_HEADER, 0);

  curl_setopt($session, CURLOPT_RETURNTRANSFER, 1);

  // echo "\nsession = "; var_dump($session);

  $response = curl_exec($session);

 


What might be wrong?


  --Lars Greninger


13:15CDT


I now have a tcpdump of the POST traffic but have no idea what's going on since all is encrypted. :-(


 


15:45CDT


I've examined in Wireshark the packets at the transition from a GET to a GET and at the transition from a GET to a POST.  They suggest that, for some reason, the SSL handshake had to be completely renegotiated at the POST and that this rengotiation failed.  Here are the packet sequences:


A GET followed by a GET

me => cc    Encrypted Alert    seq=567, ack=10833, len=23

me => cc    FIN, ACK    seq=590, ack=10833

me => cc    SYN        seq=0, win=5840

cc => me    SYN, ACK    seq=0, ack=1

me => cc    ACK        seq=1, ack=1

me => cc    A Client Hello    seq=1, ack=1, len=126







A GET followed by a POST w/o cert:

me => cc    Encrypted Alert    seq=567, ack=10833, len=23

me => cc    FIN, ACK    seq=590, ack=10833

me => cc    SYN        seq=0, win=0

cc => me    FIN, ACK    seq=10833, ack=590

me => cc    ACK        seq=591, ack=10834

cc => me    FIN, ACK    seq=10833, ack=591

cc => me    SYN, ACK    seq=0, ack=1

me => cc    ACK        seq=1, ack=1

me => cc    Client Hello    seq=1, ack=1, len=126

cc => me    Server Hello, Cert, Server Hello done

                seq=1, ack=127, len=867

me => cc    ACK        seq=127, ack=868

me => cc    Client Key Exch, Ch Cipher Spec

                seq=127, ack=868, len=183

cc => me    Ch Cipher Spec    seq=868, ack=309, len=43

me => cc    TCP seg rea PDU    seq=309, ack=911, len=1448

me => cc    Applicatn Data    seq=1757, ack=911, len=491

cc => me    ACK        seq=911, ack=1757

cc => me    Applicatn Data    seq=911, ack=2248, len=371

me => cc    Encrypted Alert

me => cc    FIN, ACK    seq=2271, ack=1282

cc => me    FIN, ACK    seq=1281, ack=2271

me => cc    ACK        seq=2272, ack=1283

cc => me    FIN, ACK    seq=1282, ack-2272

 


I'll send the tcpdump if you'd like.


  --Lars


16:06CDT


I just realized I was a bit hasty in cutting off recording the "GET followed by a GET" case.  It looks a lot like the "GET followed by a POST" case except the renegotiation worked.  Here is the full sequence of packets:


A GET followed by a GET

me => cc    Encrypted Alert    seq=567, ack=10833, len=23

me => cc    FIN, ACK    seq=590, ack=10833

me => cc    SYN        seq=0, win=5840

cc => me    SYN, ACK    seq=0, ack=1

me => cc    ACK        seq=1, ack=1

me => cc    A Client Hello    seq=1, ack=1, len=126

cc => me    FIN, ACK    seq=10833, ack=590

me => cc    ACK        seq=591, ack=10834

cc => me    Server Hellow, Cert, Server Hello Done

                seq=1, ack=127, len=867

me => cc    ACK        seq=127, ack=868

me => cc    Client Key Exch, Ch Cipher Spec

                seq=127, ack=868, len=182

cc => me    Change Cipher Spec

                seq=868, ack=309, len=43

me => cc    Appl Data    seq=309, ack=911, len=258

cc => me    TCP seg rea PDU    seq=911, ack=567, len=1448

cc => me    Appl Data    seq=2359, ack=567, len=1448

me => cc    ACK        seq=567, ack=3807

cc => me    Appl Data    seq=3807, ack=567, len=1448

cc => me    Appl Data    seq=5255, ack=567, len=1448

me => cc    ACK        seq=567, ack=6703

cc => me    Appl Data    seq=6703, ack=567, len=1448

cc => me    Appl Data    seq=8151, ack=567, len=1448

me => cc    ACK        seq=567, ack=9599

cc => me    Appl Data    seq=9599, ack=567, len=1234

me => cc    Encrypted Alert    seq=567, ack=10833, len=23

 


  --Lars


22:05CDT


One more small bit of information: my Curl s/w level:


    curl 7.12.1 (i686-redhat-linux-gnu) libcurl/7.12.1 OpenSSL/0.9.7a zlib/1.2.1.2 libidn/0.5.6


  --Lars


22:35CDT


I just added a


      curl_setopt($session, CURLOPT_VERBOSE, TRUE);


and saw a


     HTTP/1.1 409 Conflict.


just as I was doing the POST.  What CC rule could I be violating to cause a 409 error response from CC?


Adding a


   curl_setopt($session, CURLOPT_FRESH_CONNECT, TRUE);


to prevent reuse of the GET connection did not help.


  --Lars

Lars Greninger


Hero Arts development

Highlighted
Moderator

Hi Lars,   You may see 409

Hi Lars,


 


You may see 409 errors if you made changes to the URIs in your XML.  The XML requires all the URIs to be http and NOT https.  If you changed any of them to https, you may see 409 or 415 errors when trying to do POST and PUT requests.

Dave Berard
Senior Product Manager, Constant Contact
Developer Portal

View API documentation, code samples, get your API key.

Visit Page

Constant Contact 2020 End of Summer Community Sweepstakes!

The Constant Contact User Community is hosting a sweepstakes. The more you participate, the more chances you have to win! Read on to learn more...

Read More
Featured