Closed Bug 865614 Opened 11 years ago Closed 11 years ago

Purchase fails due to POST /app/test-app-test42/purchase/webpay/prepare_pay returning a 403 on stage

Categories

(Marketplace Graveyard :: Payments/Refunds, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
2013-05-30

People

(Reporter: krupa.mozbugs, Assigned: kumar)

References

Details

(Keywords: regression)

Country: Spain
Language setting on phone: Espanol

steps to reproduce:
1. Launch marketplace stage
2. Find a paid app
3. Click on the purchase button


expected behavior:
Purchase flow begins within a trusted UI


http request [
POST /app/test-app-test21/purchase/webpay/prepare_pay HTTP/1.1
Host: marketplace.allizom.org
User-Agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0
Accept: */*
Accept-Language: es,es-ES;q=0.8,es;q=0.6,en-US;q=0.4,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: https://marketplace.allizom.org/app/test-app-test21/?src=mkt-search
X-CSRFToken: Rbuz4RmKFdu6uuv4sekPpFg4kPGHINnx
X-Requested-With: XMLHttpRequest
Cookie: __utma=42843833.2081127502.1366815441.1366825033.1366878569.5; __utmz=42843833.1366815441.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utmb=42843833.42.10.1366878569; gaia=true; __utmc=42843833; mobile=true; lang="es\054"; region=es; multidb_pin_writes=y
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0
]
I/PRLog   (  108): 2013-04-25 10:38:30.709683 UTC - 28516800[40404470]: nsHttpTransaction::HandleContentStart [this=48c83f50]
Duration:        0.342 48c83f50       (marketplace.allizom.org -> POST /app/test-app-test21/purchase/webpay/prepare_pay)
http response [
HTTP/1.1 403 FORBIDDEN
Server: gunicorn/0.15.0
Vary: X-Requested-With, Accept-Language, Cookie, X-Mobile, User-Agent, Accept-Encoding
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Access-Control-Expose-Headers: X-API-Filter, X-API-Status, X-API-Version
Strict-Transport-Security: max-age=2592000
Date: Thu, 25 Apr 2013 10:38:29 GMT
Transfer-Encoding: chunked
x-content-security-policy-report-only: policy-uri /services/csp/policy?build=3a3a
Via: Moz-pp-zlb09
Connection: keep-alive
Set-Cookie: multidb_pin_writes=y; expires=Thu, 25-Apr-2013 10:38:44 GMT; Max-Age=15; Path=/
Access-Control-Allow-Headers: X-HTTP-Method-Override, Content-Type
]

observed behavior:
Purchase fails due to POST /app/test-app-test42/purchase/webpay/prepare_pay returning a 403 on stage
I can't find anything in the logs that caused this 403. Perhaps we are missing some log messages for 403 responses. 

There was an 'Already purchased' message but earlier on in the log, not when krupa pressed the pay button. Maybe that set the phone into some weird state though.

Apr 25 02:56:56 web2.stage.addons.phx1.mozilla.com: [krupamozbugs44][195.235.76.17] mkt.purchase:INFO Already purchased: 436275 :/data/www/addons.allizom.org/zamboni/apps/addons/decorators.py:
98

Note that the actual 403s were happening closer to Apr 25 04:14:42
I can't think of any action to take on this bug right now. Let's revisit if it happens again.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
I just reproduce this issue. I think purchase is broken for users who are already logged-in.

STR:
1. Log in from the Settings page on Marketplace stage
2. Do a blank search and then filter for paid
3. Click on the purchase button for one of the listed paid apps

purchase fails with a 403 

If the user logged in while doing a purchase, the future purchases go through without any issues. Looks like webpay is not recognizing the logged-in status from Marketplace.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Starting: 47aa0d20
http request [
POST /app/private-yacht/purchase/webpay/prepare_pay HTTP/1.1
Host: marketplace.allizom.org
User-Agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://marketplace.allizom.org/search/?price=paid&q=&sort=
X-CSRFToken: VtG1JhJCxLHMt8gAaSa5Ca2h0Bw0jkVw
X-Requested-With: XMLHttpRequest
I/PRLog   (  109):   Cookie: __utma=42843833.1474153420.1367536544.1367617384.1367621355.7; __utmz=42843833.1367536544.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); mobile=true; lang="en-US\054"; region=us; carrier=telefonica; __utmb=42843833.10.10.1367621355; __utmc=42843833; gaia=true; sessionid=".eJxrYKotZNQI5UouLkqLL8nPTs0rZApVSAvNNbG0CA0wq_TKcTP0j6j0zi8zSU8OKfMOMStzL0ouZA7ljU8sLcmILy1OLYrPTClk6WIWVEoPFUISTUpMBhqXUsgaqpaSlZiXnh-fVJRfDpTJTNEDqdJzgnA9XZygKtlK9QDOnjI7:1UYOnF:vyKjfPY13RfoBni9GRdzy-w91U4"; multidb_pin_writes=y
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0
]
I/PRLog   (  109): 2013-05-03 22:50:15.895809 UTC - 2977744[40304470]: nsHttpTransaction::HandleContentStart [this=47aa0d20]
Duration:        0.172 47aa0d20       (marketplace.allizom.org -> POST /app/private-yacht/purchase/webpay/prepare_pay)
http response [
HTTP/1.1 403 FORBIDDEN
Server: gunicorn/0.15.0
Vary: X-Requested-With, Accept-Language, Cookie, X-Mobile, User-Agent, Accept-Encoding
Cache-Control: no-cache
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Access-Control-Expose-Headers: X-API-Filter, X-API-Status, X-API-Version
Strict-Transport-Security: max-age=2592000
Date: Fri, 03 May 2013 22:50:17 GMT
Transfer-Encoding: chunked
-content-security-policy-report-only: policy-uri /services/csp/policy?build=6d6d
Via: Moz-pp-zlb09
Connection: keep-alive
Set-Cookie: multidb_pin_writes=y; expires=Fri, 03-May-2013 22:50:32 GMT; Max-Age=15; Path=/
Access-Control-Allow-Headers: X-HTTP-Method-Override, Content-Type
]
Severity: blocker → normal
Kumar says fireplace will fix this
This sounds like something Fireplace will fix because it won't require the app to be reloaded upon login. Maybe we can try to reproduce in Fireplace when payments are working there.
In Fireplace we don't even use that URL, we use the new API.
It's the same URL handler just wrapped in API goodness http://firefox-marketplace-api.readthedocs.org/en/latest/topics/payment.html#post--api-v1-webpay-prepare-

I think the 403 in Krupa's case is due to weird session/login state caused by the old Marketplace app.
Fireplace is glowing bright on dev/stage! Krupa, can you try to reproduce now?
I will keep an eye out for this issue. I think i saw it recently enough though
(In reply to krupa raj 82[:krupa] from comment #10)
> I will keep an eye out for this issue. I think i saw it recently enough
> though

We're 6 days in, have you seen it?  Can we close this?
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2013-05-30
I haven't seen this issue. Will file a new bug if it resurfaces.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.