831401 - Redirected to generic Bango error page on cancel

Status: RESOLVED FIXED

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

Description

[Kumar McMillan [:kumar]]

In Andy's setup he can produce an error where Bango redirects to a generic error URL (mozilla.com) instead of the one configued by the Billing Configuration API call.

He sees the confirmation page then clicks cancel and is redirected to the wrong place.

Example URL: http://mozilla.test.bango.org/mozpayments/?bcid=5150

Example SOAP request:

10:34:1358361274 suds.client:DEBUG sending to (https://webservices.test.bango.org/billingconfiguration/service.asmx)
message:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:ns0="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="com.bango.webservices.billingconfiguration" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <ns0:Body>
      <ns1:CreateBillingConfiguration>
         <ns1:request>
            <ns1:username>Mozilla</ns1:username>
            <ns1:password>***</ns1:password>
            <ns1:bango>111333805590</ns1:bango>
            <ns1:typeFilter>
               <ns1:string>OPERATOR</ns1:string>
               <ns1:string>PSMS</ns1:string>
               <ns1:string>CARD</ns1:string>
               <ns1:string>INTERNET</ns1:string>
            </ns1:typeFilter>
            <ns1:priceList>
               <ns1:Price>
                  <ns1:amount>1.99</ns1:amount>
                  <ns1:currency>USD</ns1:currency>
               </ns1:Price>
            </ns1:priceList>
            <ns1:externalTransactionId>webpay:45fcb4f4-c0aa-47f7-a78e-ba6c3b4dc8af</ns1:externalTransactionId>
            <ns1:pageTitle>Test App (foosdfpsdfyasdad)</ns1:pageTitle>
            <ns1:configurationOptions>
               <ns1:BillingConfigurationOption>
                  <ns1:configurationOptionName>APPLICATION_CATEGORY_ID</ns1:configurationOptionName>
                  <ns1:configurationOptionValue>18</ns1:configurationOptionValue>
               </ns1:BillingConfigurationOption>
               <ns1:BillingConfigurationOption>
                  <ns1:configurationOptionName>BILLING_CONFIGURATION_TIME_OUT</ns1:configurationOptionName>
                  <ns1:configurationOptionValue>120</ns1:configurationOptionValue>
               </ns1:BillingConfigurationOption>
               <ns1:BillingConfigurationOption>
                  <ns1:configurationOptionName>REDIRECT_URL_ONERROR</ns1:configurationOptionName>
                  <ns1:configurationOptionValue>http://z.mozilla.dev/mozpay/bango/error</ns1:configurationOptionValue>
               </ns1:BillingConfigurationOption>
               <ns1:BillingConfigurationOption>
                  <ns1:configurationOptionName>REQUEST_SIGNATURE</ns1:configurationOptionName>
                  <ns1:configurationOptionValue>93efec5670e7ed9db7e374fa3d892e181bbb0f4debc42cd8455124054f9bc611</ns1:configurationOptionValue>
               </ns1:BillingConfigurationOption>
               <ns1:BillingConfigurationOption>
                  <ns1:configurationOptionName>REDIRECT_URL_ONSUCCESS</ns1:configurationOptionName>
                  <ns1:configurationOptionValue>http://z.mozilla.dev/mozpay/bango/success</ns1:configurationOptionValue>
               </ns1:BillingConfigurationOption>
               <ns1:BillingConfigurationOption>
                  <ns1:configurationOptionName>APPLICATION_SIZE_KB</ns1:configurationOptionName>
                  <ns1:configurationOptionValue>2</ns1:configurationOptionValue>
               </ns1:BillingConfigurationOption>
            </ns1:configurationOptions>
         </ns1:request>
      </ns1:CreateBillingConfiguration>
   </ns0:Body>
</SOAP-ENV:Envelope> :/Users/andy/.virtualenvs/solitude/lib/python2.6/site-packages/suds/client.py:624

Comment 1

[Keir Kettle]

Quick explanation of the cause of the issue: Bango runs mainly on MS tech, and all web apps run on IIS. IIS allows webapps to be assigned to a 'app pool'. All apps in a app pool share the same worker process, and as such any app in the pool can cause an issue that can prompt the pool to need to be recycled (clearly multiple apps per app pool is not recommended, and won't be the case, for 'live' services). 

Anyway, we use the session to hold the detail of the current moz request (which allows state to be maintained between http backwards and forwards). When a app pool is recycled, all sessions are lost.  The reason for the above recycle was due to another app in the same pool exceeding the execution time.

Currently our handling of sessions being unavailable is pretty basis (if session is null redirect to hardcoded url), so I suggest we make this smarter (we could look up the correct error from the billing config id for example).

My question is, if everything has melted and we can retrieve the url, what should be the worse case behavior? I guess a hard-coded url isnt useful, a 500 status code, maybe? 

Thanks

Comment 2

[Kumar McMillan [:kumar]]

While in development, what would be useful is a bango hosted page that shows what the error query string is so we can at least see it. In production, you may want to make it a 500 Internal Error so that the info can be fetched from a log.

Comment 3

[Kumar McMillan [:kumar]]

Keir, thanks for the insight. This seems to explain the random errors. However, Andy hits this error every single time :( Is there any way to look up the config ID to see if there is another error at work?

Comment 4

[Kumar McMillan [:kumar]]

The cancel button is redirecting to our pre-configured error page now, thanks!