864840 - Purchase on wifi fails with 400 bad request

Status: RESOLVED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect)

Description

[krupa raj[:krupa]]

Attachment: logs

country: Spain

steps to reproduce:
1. Make sure you have logged out of marketplace stage
2. Start app purchase
3. Sign in as a new user
4. Create PIN


expected behavior:
Confirm your mobile number screen loads


observed behavior:
Blank screen loads due to 400 Bad request

Starting: 47ebeef0
I/PRLog   (  108): 2013-04-23 16:25:18.848996 UTC - 1074783480[40404160]: http request [
I/PRLog   (  108): 2013-04-23 16:25:18.850064 UTC - 1074783480[40404160]:   GET /mobileid/v1/owd01?x-ob=21407&Bango=1113330000000373796&BID=19335&BIDT=9908cd3c-8d9d-4ceb-aff7-ed13a9508d2c HTTP/1.1
I/PRLog   (  108): 2013-04-23 16:25:18.850552 UTC - 1074783480[40404160]:   Host: partners-api.bluevia.com
I/PRLog   (  108): 2013-04-23 16:25:18.850949 UTC - 1074783480[40404160]:   User-Agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0
I/PRLog   (  108): 2013-04-23 16:25:18.851010 UTC - 1074783480[40404160]:   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
I/PRLog   (  108): 2013-04-23 16:25:18.851041 UTC - 1074783480[40404160]:   Accept-Language: en-US,en;q=0.5
I/PRLog   (  108): 2013-04-23 16:25:18.851102 UTC - 1074783480[40404160]:   Accept-Encoding: gzip, deflate
I/PRLog   (  108): 2013-04-23 16:25:18.851132 UTC - 1074783480[40404160]:   Connection: keep-alive
I/PRLog   (  108): 2013-04-23 16:25:18.851193 UTC - 1074783480[40404160]: ]
I/PRLog   (  108): 2013-04-23 16:25:19.175870 UTC - 12726720[40404470]: nsHttpTransaction::HandleContentStart [this=47ebeef0]
Duration:        0.327 47ebeef0       (partners-api.bluevia.com -> GET /mobileid/v1/owd01?x-ob=21407&Bango=1113330000000373796&BID=19335&BIDT=9908cd3c-8d9d-4ceb-aff7-ed13a9508d2c)
I/PRLog   (  108): 2013-04-23 16:25:19.176602 UTC - 12726720[40404470]: http response [
I/PRLog   (  108): 2013-04-23 16:25:19.176724 UTC - 12726720[40404470]:   HTTP/1.1 400 Bad Request
I/PRLog   (  108): 2013-04-23 16:25:19.176755 UTC - 12726720[40404470]:   Connection: close
I/PRLog   (  108): 2013-04-23 16:25:19.176816 UTC - 12726720[40404470]:   Content-Length: 0
I/PRLog   (  108): 2013-04-23 16:25:19.176846 UTC - 12726720[40404470]: ]

Comment 1

[Keir Kettle]

The 400 comes from here : 

(partners-api.bluevia.com -> GET /mobileid/v1/owd01?x-ob=21407&Bango=1113330000000373796&BID=19335&BIDT=9908cd3c-8d9d-4ceb-aff7-ed13a9508d2c)

Can telefonica investigate?

Comment 2

[Jorge Vila]

Hi,

would it be possible to have the IP of the device originating the request?

This 400 Bad Request can only happen when the IP is not recognized as a valid IP and it is considered an attack in the firewall.

Jorge

Comment 3

[Jorge Vila]

Reproduciong the issue: mobile id is being called through wifi.

IP = 213.0.81.93 is not in the mobile data network list.

Request from Bango to Mobile ID:

GET /mobileid/v1/owd01?x-ob=21407&Bango=1113330000000373796&BID=19395&BIDT=e7315197-aae9-4858-8359-48da3f4c4034 HTTP/1.1
Host: partners-api.bluevia.com
User-Agent: Mozilla/5.0 (Mobile; rv:18.0) Gecko/18.0 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
X-Forwarded-For: 213.0.81.93

BlueVia is answering:

HTTP/1.1 400 Bad Request
Connection: close
Content-Length: 0

Two options here:
1) Bango to not call mobile id when the request is not originated by the device in the mobile data network and use fallback SMS identification
2) Bango to be able to manage HTTP 400 responses and go to the fallback SMS identification.

Best
JORGE

Comment 4

[Kumar McMillan [:kumar]]

(In reply to Jorge Villa from comment #3)
> 1) Bango to not call mobile id when the request is not originated by the
> device in the mobile data network and use fallback SMS identification

This requires permissions to use the mobile connection API which we won't have on device for v1 (https://wiki.mozilla.org/WebAPI/WebMobileConnection)

> 2) Bango to be able to manage HTTP 400 responses and go to the fallback SMS
> identification.

This may be a safer approach compared to IP whitelisting since IPs can change.

Comment 5

[Keir Kettle]

Bango payment integration engineers have found the cause of this issue and fixed it.