Hi Nick,

The unsuccessful calls are intentional.
The Javascript client attempts polling for WebOTT to be authenticated by the 
user using the Mobile apps.
The calls will turn successful right after you authenticate the Access Number 
using the Mobile apps.

About the www-autentivate header, I think we need more information to reproduce 
it.
Accessing our sample Milagro MFA server 
(https://public.milagro.io/rps/accessnumber), I got the response header as 
shown below.

$ curl -v -X POST -d  "{\"webOTT\":\"428e2b2975e80e9f2119086c27ad34ea\"}" 
https://public.milagro.io/rps/accessnumber
(snip)
< HTTP/1.1 401 Unauthorized
< Date: Wed, 01 Jun 2016 17:27:39 GMT
< Server: TornadoServer/4.1
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: Content-Type, Depth, User-Agent, X-File-Size, 
X-Requested-With, X-Requested-By, If-Modified-Since, X-File-Name, Cache-Control
< Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: mpindemo_session=05301611-977A-EA38-B168-CDE28221FEA9; 
Max-Age=14400; HttpOnly; Secure
<

Regards,
Go Yamamoto
________________________________________
From: Nick Kew <[email protected]>
Sent: Wednesday, June 1, 2016 7:53:02 AM
To: [email protected]
Subject: Multiple calls to /rps/accessnumber

I've been running some M-Pin sessions capturing
and looking at the traffic between the Miracl
Javascript client and Python RP server.

Among other things, I see repeated unsuccessful calls:

POST /rps/accessnumber HTTP/1.1^M
....
Content-Type: text/plain;charset=UTF-8^M
Cookie: mpindemo_session="..."^M
^M
{"webOTT":"13468f969413889e287a69ddc526fef6"}

(aside: that's JSON being sent as text/plain)

Now the response to this is a 401, with other HTTP headers
whose legitimacy might be in question, and no body:

HTTP/1.1 401 Unauthorized^M
Server: TornadoServer/4.1^M
Www-Authenticate: Authenticate^M
[more]

I guess the "Authenticate" value to WWW-Authenticate is handled
by the Javascript, but shouldn't the browser itself be presented
with something it knows?  Conventional values are Basic or Digest
(with appropriate parameters).

What I'm seeing is what looks like "undefined" browser behaviour
in response to an unknown WWW-Authenticate.  That is to say, the
browser sends off an identical request and receives an identical
reply, repeated many times while slower human interaction takes
place as I (successfully or otherwise) log in.

Also, at no point in the interaction is there a successful
call to /rps/accessnumber .  Always 401 as above.

How much of this is intentional, and why?

--
Nick Kew

________________________________
This email message is intended for the use of the person to whom it has been 
sent, and may contain information that is confidential or legally protected. If 
you are not the intended recipient or have received this message in error, you 
are not authorized to copy, distribute, or otherwise use this message or its 
attachments. Please notify the sender immediately by return e-mail and 
permanently delete this message and any attachments. NTTI3 makes no warranty 
that this email is error or virus free. Thank you.
________________________________

Reply via email to