Expected API Response - Delete All Users

Edit

Ryan Johnston

24 Aug, 2015 03:15 PM

I'm updating the sharpy client to include promotions (coupon codes).
https://github.com/SeanOC/sharpy (original)
https://github.com/SmartFile/sharpy (updates)

I'm trying to get the unit test to work. I'm having a little trouble with expected results from the api. The first question was on a bad request.
https://cheddargetter.com/xml/plans/productCode/SHARPY_UNIT_TESTS
This now returns a 404. However the unittests act like they expect it to return a 400. Obviously it is missing the /get part of the url. A 404 seems valid to me. Did this change from a 400 to a 404 at some point in the last 4 years?

The second thing is deleting all customers. The unit tests use this method between tests to clean up.
https://cheddargetter.com/xml/customers/delete-all/confirm/[current unix timestamp]/productCode/SHARPY_UNIT_TESTS
Obviously, current time stamp is filled in when I call it. The response simply says user. I'm not sure if that one word response means I have an issue. This seems like an issue on the cheddar side because it isn't an xml response. It also does not delete all customers.
Do I need to update something in the settings to make delete all customers work on a development account? What is the expected response for delete all customers api endpoint?
https://cheddargetter.com/developers#delete-all-customers

Ryan Johnston
SmartFile

Support Staff 1 Posted by Marc Guyer on 25 Aug, 2015 06:27 PM
I'm trying to get the unit test to work. I'm having a little trouble with expected results from the api. The first question was on a bad request. https://cheddargetter.com/xml/plans/productCode/SHARPY_UNIT_TESTS This now returns a 404. However the unittests act like they expect it to return a 400. Obviously it is missing the /get part of the url. A 404 seems valid to me. Did this change from a 400 to a 404 at some point in the last 4 years?

I honestly can't be sure. Based on my knowledge of our routing, I don't see how that could possibly be anything but a 404. We don't have any special routing for plans/get so that would literally mean plans controller and productCode action which doesn't exist.

The response simply says user. I'm not sure if that one word response means I have an issue. This seems like an issue on the cheddar side because it isn't an xml response. It also does not delete all customers.

I just ran a test of this and I'm unable to confirm. This endpoint behaves as expected. Do you happen to have the raw response logged for this? I suspect that there's something else in play...

Do I need to update something in the settings to make delete all customers work on a development account?

No

What is the expected response for delete all customers api endpoint?

As usual, it's a 200 status. The body is
```
<?xml version="1.0" encoding="UTF-8"?>
<success/>
```
- Edit

2 Posted by Ryan Johnston on 25 Aug, 2015 06:51 PM

Agreed, there probably is something else at play here. I'm definitely only getting user as the response. I get the same result in the browser and in my code.

Here is a browser request.
Request Headers

Accept:  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Connection: keep-alive
Cookie: CGMK=%7B%22firstContactDatetime%22%3A%222015-03-20T19%3A34%3A21%2B00%3A00%22%2C%22referer%22%3A%22direct
%22%2C%22campaignTerm%22%3A%22%22%2C%22campaignName%22%3A%22%28direct%29%22%2C%22campaignSource%22%3A
%22%28direct%29%22%2C%22campaignMedium%22%3A%22%28none%29%22%2C%22campaignContent%22%3A%22%22%7D; __utma
=91078085.357811377.1426880062.1440448237.1440510155.63; __utmz=91078085.1440428018.59.5.utmcsr=google
|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); hblid=gswwnvozwG5DBI2w2Y7z87S7JTOy02Ba; olfsk
=olfsk15316050927500635; ga=GA1.2.1679073359.1427737298; chdrgtr=vo9d1oet5v96fn5c2044jdqq92; CHEDDARGETTER
=hq81q4j8j7dmjggg8p8orvp444; __utmc=91078085; wcsid=tjY43QvlU3wcXSvL2Y7z80S5JT2GBDnM; _oklv=1440510218922
%2CtjY43QvlU3wcXSvL2Y7z80S5JT2GBDnM; _okdetect=%7B%22token%22%3A%2214405101762250%22%2C%22proto%22%3A
%22http%3A%22%2C%22host%22%3A%22support.cheddargetter.com%22%7D; _okbk=cd4%3Dtrue%2Cvi5%3D0%2Cvi4%3D1440510176377
%2Cvi3%3Dactive%2Cvi2%3Dfalse%2Cvi1%3Dfalse%2Ccd8%3Dchat%2Ccd6%3D0%2Ccd5%3Daway%2Ccd3%3Dfalse%2Ccd2%3D0
%2Ccd1%3D0%2C; _ok=7734-706-10-7962; K-CHEDDARGETTER-omldmiif=457A8415F974F1965CBF55C08E0CA478; CGHSTD
=fvi5mqg05l6bu61bkt3egne3v3
Host: cheddargetter.com
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x8664; rv:39.0) Gecko/20100101 Firefox/39.0

Response Headers

HTTP/1.1 200 OK
Server: Apache/2.2.22 (Ubuntu)
Vary: Accept-Encoding
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: text/html; charset=UTF-8
Content-Encoding: gzip
Date: Tue, 25 Aug 2015 18:33:31 GMT
Node: CHED01VMW02
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Connection: Keep-Alive
Content-Length: 24

Body

user

In the Python code:
url

POST https://cheddargetter.com/xml/customers/delete-all/confirm/1440528469/productCode/SHARPY_UNIT_TESTS

It's using Basic Authentication.

Response Headers

{
'node': 'CHED01VMW02',
'status': '200',
'content-length': '4',
'set-cookie': 'CHEDDARGETTER=**************************;
expires=Thu, 24-Sep-2015 18:41:42 GMT;
path=/;
domain=cheddargetter.com',
'expires': 'Thu, 19 Nov 1981 08:52:00 GMT',
'vary': 'Accept-Encoding',
'server': 'Apache/2.2.22 (Ubuntu)',
'connection': 'Keep-Alive',
'-content-encoding': 'gzip',
'pragma': 'no-cache',
'cache-control': 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0',
'date': 'Tue, 25 Aug 2015 18:41:42 GMT',
'content-type': 'text/html; charset=UTF-8'}

Body

user

Edit

Support Staff 3 Posted by Marc Guyer on 25 Aug, 2015 07:52 PM

That is very strange. I'm still unable to replicate that -- browser or curl, I always get the expected response.

Here's something: I was combing our web logs and found that your requests appear to always be of the strict 401/200 variety. According to spec, the request is supposed to be sent without auth, then when the 401 response is received, the request is resent with the auth header. That procedure makes it possible for the client to analyze the response headers and determine the best method of auth. Most http libs recognize that the auth params have already been provided and so they're sent in the original request, avoiding the need for the second request. That goes against spec but it's clearly more efficient and most often the desired behavior. Httplib2 does it the strict way. We know that the auth method is basic so there's no need for the double round-trip. You can force httplib2 to include the auth header in the initial request but I don't recall the recommended way. On the most basic level, you could just build the auth header and add it to the request directly. Httplib2 might have a more convenient way of doing that.

I don't have any evidence of that being the problem here. I suggest doing the workaround anyway and see if you get different behavior. That would at least give us something to go on.
- Edit
4 Posted by Ryan Johnston on 25 Aug, 2015 08:00 PM
Can you give me the curl request (without your credentials of course)? I'm interested in seeing if I can get the correct xml back and work backwords.

I am using httplib2. I'm pretty sure I am forcing it to include the auth in the initial request.
```
    username = config['cheddar']['username']
    password = config['cheddar']['password']
    h = httplib2.Http()
    h.add_credentials(username, password)
```
- Edit

Support Staff 5 Posted by Marc Guyer on 25 Aug, 2015 08:09 PM

Even though it has the auth params, it insists on getting the 401 before it will resend with the auth header. You have to workaround that. Here's an example where the header is built and given to the request method:

https://josephscott.org/archives/2011/06/http-basic-auth-with-httpl...

Curl doesn't do the 401 thing. You can force it to with the --anyauth flag if you want. Here it is without:

$ curl -v -u [email blocked]:xxxxx https://cheddargetter.com/xml/customers/delete-all/productCode/test_delete/confirm/1440531009
* Adding handle: conn: 0x7fdc71017a00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fdc71017a00) send_pipe: 1, recv_pipe: 0
* About to connect() to cheddargetter.com port 443 (#0)
*   Trying 198.90.23.195...
* Connected to cheddargetter.com (198.90.23.195) port 443 (#0)
* TLS 1.2 connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate: *.cheddargetter.com
* Server certificate: Go Daddy Secure Certificate Authority - G2
* Server certificate: Go Daddy Root Certificate Authority - G2
* Server certificate: Go Daddy Class 2 Certification Authority
* Server auth using Basic with user '[email blocked]'
> GET /xml/customers/delete-all/productCode/test_delete/confirm/1440531009 HTTP/1.1
> Authorization: Basic xxx
> User-Agent: curl/7.30.0
> Host: cheddargetter.com
> Accept: */*
> 
< HTTP/1.1 200 OK
* Server Apache/2.2.22 (Ubuntu) is not blacklisted
< Server: Apache/2.2.22 (Ubuntu)
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Content-Type: application/xml
< Date: Tue, 25 Aug 2015 19:48:26 GMT
< Node: CHED01VMW02
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< Connection: Keep-Alive
< Set-Cookie: CHEDDARGETTER=lu7716qjdj3tsak6u73ntnmcs2; expires=Thu, 24-Sep-2015 19:48:26 GMT; path=/; domain=cheddargetter.com
< Content-Length: 50
< 
<?xml version="1.0" encoding="UTF-8"?>
<success/>

Edit

6 Posted by Ryan Johnston on 25 Aug, 2015 08:29 PM

It hates me. Even with curl.

curl -v -u [email blocked]:xxxxx https://cheddargetter.com/xml/customers/delete-all/productCode/SHARPY_UNIT_TESTS/confirm/1440534300
*   Trying 198.90.23.195...
* Connected to cheddargetter.com (198.90.23.195) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
*   subject: CN=*.cheddargetter.com,OU=Domain Control Validated
*   start date: Jul 12 15:43:38 2015 GMT
*   expire date: Jul 12 15:43:38 2016 GMT
*   common name: *.cheddargetter.com
*   issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US
* Server auth using Basic with user '[email blocked]'
> GET /xml/customers/delete-all/productCode/SHARPY_UNIT_TESTS/confirm/1440534300 HTTP/1.1
> Authorization: Basic xxx=
> User-Agent: curl/7.40.0
> Host: cheddargetter.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache/2.2.22 (Ubuntu)
< Vary: Accept-Encoding
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Content-Type: text/html; charset=UTF-8
< Date: Tue, 25 Aug 2015 20:25:10 GMT
< Node: CHED01VMW01
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< Connection: Keep-Alive
< Set-Cookie: CHEDDARGETTER=pn66so4hg1mqjekm00ont88qr4; expires=Thu, 24-Sep-2015 20:25:10 GMT; path=/; domain=cheddargetter.com
< Content-Length: 4
< 
* Connection #0 to host cheddargetter.com left intact
user

I guess we can rule out CHED01VMW01 vs CHED01VMW02. Now I've hit both of them.

Edit

Support Staff 7 Posted by Marc Guyer on 25 Aug, 2015 08:34 PM

Can you confirm from a different network?
- Edit

8 Posted by Ryan Johnston on 25 Aug, 2015 08:44 PM

Here is the same curl request from a different machine in Florida:

$ curl -v -u [email blocked]:xxxxx https://cheddargetter.com/xml/customers/delete-all/productCode/SHARPY_UNIT_TESTS/confirm/1440531009
* About to connect() to cheddargetter.com port 443 (#0)
*   Trying 198.90.23.195... connected
* Connected to cheddargetter.com (198.90.23.195) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
*   subject: CN=*.cheddargetter.com,OU=Domain Control Validated
*   start date: Jul 12 15:43:38 2015 GMT
*   expire date: Jul 12 15:43:38 2016 GMT
*   common name: *.cheddargetter.com
*   issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US
* Server auth using Basic with user '[email blocked]'
> GET /xml/customers/delete-all/productCode/SHARPY_UNIT_TESTS/confirm/1440531009 HTTP/1.1
> Authorization: Basic xxx=
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: cheddargetter.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache/2.2.22 (Ubuntu)
< Vary: Accept-Encoding
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Content-Type: text/html; charset=UTF-8
< Date: Tue, 25 Aug 2015 20:40:24 GMT
< Node: CHED01VMW01
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< Connection: Keep-Alive
< Set-Cookie: CHEDDARGETTER=jdlu8ltohprjlfa3cps0nqirj2; expires=Thu, 24-Sep-2015 20:40:24 GMT; path=/; domain=cheddargetter.com
< Content-Length: 4
< 
* Connection #0 to host cheddargetter.com left intact
* Closing connection #0
user

Edit

9 Posted by Ryan Johnston on 25 Aug, 2015 08:52 PM

Here is another one from a server over at IUPUI:

curl -v -u [email blocked]:xxxxx https://cheddargetter.com/xml/customers/delete-all/productCode/SHARPY_UNIT_TESTS/confirm/1440535274
* About to connect() to cheddargetter.com port 443 (#0)
*   Trying 198.90.23.195... connected
* Connected to cheddargetter.com (198.90.23.195) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
*     subject: CN=*.cheddargetter.com,OU=Domain Control Validated
*     start date: Jul 12 15:43:38 2015 GMT
*     expire date: Jul 12 15:43:38 2016 GMT
*     common name: *.cheddargetter.com
*     issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US
* Server auth using Basic with user '[email blocked]'
> GET /xml/customers/delete-all/productCode/SHARPY_UNIT_TESTS/confirm/1440535274 HTTP/1.1
> Authorization: Basic xxx=
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.18 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: cheddargetter.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache/2.2.22 (Ubuntu)
< Vary: Accept-Encoding
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Content-Type: text/html; charset=UTF-8
< Date: Tue, 25 Aug 2015 20:48:55 GMT
< Node: CHED01VMW01
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< Connection: Keep-Alive
< Set-Cookie: CHEDDARGETTER=9fuprk1p8u69gl0fhelc1ul0o4; expires=Thu, 24-Sep-2015 20:48:55 GMT; path=/; domain=cheddargetter.com
< Content-Length: 4
< 
* Connection #0 to host cheddargetter.com left intact
* Closing connection #0
user

Thanks for all your help on this.

Edit

10 Posted by Ryan Johnston on 25 Aug, 2015 09:18 PM

Trying some different things with another developer here we have determined that you can put whatever you want after the delete-all and get the same result: user

curl -v -u [email blocked]:xxxxx https://cheddargetter.com/xml/customers/delete-all/[anything here]
*   Trying 198.90.23.195...
* Connected to cheddargetter.com (198.90.23.195) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
*   subject: CN=*.cheddargetter.com,OU=Domain Control Validated
*   start date: Jul 12 15:43:38 2015 GMT
*   expire date: Jul 12 15:43:38 2016 GMT
*   common name: *.cheddargetter.com
*   issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US
* Server auth using Basic with user '[email blocked]'
> GET /xml/customers/delete-all/ HTTP/1.1
> Authorization: Basic xxx=
> User-Agent: curl/7.40.0
> Host: cheddargetter.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: Apache/2.2.22 (Ubuntu)
< Vary: Accept-Encoding
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Content-Type: text/html; charset=UTF-8
< Date: Tue, 25 Aug 2015 21:17:49 GMT
< Node: CHED01VMW02
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< Connection: Keep-Alive
< Set-Cookie: CHEDDARGETTER=m3qu9dp9e375tbpl6gvurt43u3; expires=Thu, 24-Sep-2015 21:17:49 GMT; path=/; domain=cheddargetter.com
< Content-Length: 4
< 
* Connection #0 to host cheddargetter.com left intact
user

Also, if you tell it to return json instead of xml, it will still return user.

Bad password tries to redirect to login (302). So, it gets past authentication when it returns user.

Edit

Support Staff 11 Posted by Marc Guyer on 26 Aug, 2015 01:18 PM

It's beginning to look like the problem is specific to your account. I'd like to run some tests against your SHARPY_UNIT_TESTS account. Do I have your permission to do that?

Also, if you tell it to return json instead of xml, it will still return user.

Bad password tries to redirect to login (302). So, it gets past that when it returns user.

This is expected. There is no JSON context for this action so it behaves like a UI request. You'll find that if you use the wrong auth with the /xml/ route, you'll get the expected 401.
- Edit
12 Posted by Ryan Johnston on 26 Aug, 2015 01:37 PM

Be my guest. SHARPY_UNIT_TESTS is just a quick product that I set up to run tests outside our usual products. There is nothing that can't be recreated there.

The history on that product is that I set it up Monday. I added a few plans, tracked items, and promotion codes. I also added the Native Gateway Simulator. I updated the secret key after posting all these requests yesterday.
- Edit
Support Staff 13 Posted by Marc Guyer on 26 Aug, 2015 02:10 PM

Ok, thanks. I was able to replicate. It seems that we have an ACL bug specific to this particular action and scenario. It seems that it's deferring to the role with least permission and not assigning the appropriate role for your user. Dumping just the word "user" seems to also be related -- making this more difficult to track down. We'll get that fixed up as soon as we can. I would expect that by the end of the day. I'll keep you posted.
- Edit
Support Staff 14 Posted by Marc Guyer on 27 Aug, 2015 03:44 PM

Just a quick update... We're having some trouble getting this replicated in a dev environment. We're working on it and I'll update you when we have a solution.
- Edit
15 Posted by Ryan Johnston on 27 Aug, 2015 03:46 PM

Thanks for the update.
- Edit
Support Staff 16 Posted by Marc Guyer on 27 Aug, 2015 05:03 PM

Ok, a hotfix has been developed, tested, and deployed. Your next run should be successful. Thanks for your patience and your help with this issue!
- Edit
17 Posted by Ryan Johnston on 27 Aug, 2015 05:35 PM

The hotfix is working.

Thanks for all your help on this. You and your team have done it.
- Edit
Marc Guyer closed this discussion on 27 Aug, 2015 08:16 PM.

Discussions are closed to public comments.
If you need help with Cheddar please start a new discussion.

New Issue
Conversation Started
The discussion is closed

No more actions from Cheddar or the discussion starter are required.
Re-open the discussion Re-open the discussion

Private Permissions

This discussion is private. Only you and Cheddar support staff can see and reply to it.

Public Permissions

This discussion is public. Everyone can see and reply to it.

Comments Feed

Keyboard shortcuts

Generic

?	Show this help
ESC	Blurs the current field

Comment Form

r	Focus the comment reply box
^ + ↩	Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

	28 Mar, 2024 10:45 PM	PDF Invoices
	24 Jan, 2024 08:33 AM	Cancel Account
	11 Jan, 2024 07:13 AM	Users in my Cheddar account?
	30 Nov, 2023 02:07 AM	churn amount
	22 Nov, 2023 08:41 AM	testing

Recent Articles

	RBI regulations - context, FAQs, & next steps
	Configuring Stripe
	Configuring AuthorizeNet
	Pricing Plan Basics
	Marketing Metrics Cookie Best Practices

Expected API Response - Delete All Users

Ryan Johnston

New Issue

Conversation Started

The discussion is closed

Re-open the discussion Re-open the discussion