848972 - Purchase fails with 400 Bad Request (empty query string in Bango error redirect)

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P1)

Description

[krupa raj[:krupa]]

steps to reproduce:
1. Start the purchase of a paid app
2. Sign in using Identity
3. Enter PIN
4. Confirm your mobile phone number
5. In the Confirm your purchase screen, click on the Buy button

expected behavior:
Purchase is successful

observed behavior:
Bango error page loads due to a 400 Bad Request error.

nsHttpTransaction::HandleContentStart [this=476a0ad0]
Duration:        0.098 476a0ad0       (marketplace-dev.allizom.org -> GET /mozpay/bango/error)
http response [
HTTP/1.1 400 BAD REQUEST
Server: gunicorn/0.14.6
Vary: X-Mobile, User-Agent, Cookie, Accept-Language, Accept-Encoding
Content-Type: text/html; charset=utf-8
Encoding: gzip
Date: Thu, 07 Mar 2013 21:37:22 GMT
Via: Moz-pp-zlb09
Connection: close
Set-Cookie: webpay_anoncsrf=pj05SZTdZN9CMijbM5ZZpNL1z9Ek43Li; expires=Thu, 07-Mar-2013 23:37:22 GMT; httponly; Max-Age=7200; Path=/; secure
x-frame-options: DENY
 ]

Comment 1

[Kumar McMillan [:kumar]]

Krupa, do you still have the full http log that shows all redirects in between?

The 400 response is from a Mozilla server but it's happening because Bango sent us an empty query string. We need to pin down why that query string is empty.

Comment 2

[Kumar McMillan [:kumar]]

I found this in our logs when Keir was seeing a 400 response again:

Mar  8 02:19:03 dev1.addons.phx1.mozilla.com: [None] w.bango:INFO Bango payment notice for transaction uuid u'webpay:74a3458a-3927-4ba1-96a9-05cecea9d5ee' failed: Client Error 400: https://payments-dev.allizom.org/bango/notification/#012Content: {"moz_transaction": ["Transaction expired: webpay:74a3458a-3927-4ba1-96a9-05cecea9d5ee"]}#012 :/data/www/marketplace-dev.allizom.org-webpay/webpay/webpay/bango/views.py:45

Comment 3

[Kumar McMillan [:kumar]]

Keir, is there a way for you to check why the redirect to our error page contains no query string parameters? You can see from the log above. There is no way for us to process an error redirect without any info so we may need to return 400s for these.

Comment 4

[Kumar McMillan [:kumar]]

Ignore comment #2, that log message doesn't seem to be related to this bug

Comment 5

[Keir Kettle]

The redirect to the error page will now include the same querystring params as success (as long as they are available)