Opened 11 months ago

Closed 11 months ago

Last modified 11 months ago

#24637 closed defect (fixed)

moat: incorrect response if no bridges available

Reported by: mcs Owned by: isis
Priority: Immediate Milestone:
Component: Obfuscation/BridgeDB Version:
Severity: Normal Keywords: bridgedb-moat, bridgedb-distributors
Cc: brade Actual Points:
Parent ID: #24689 Points: 1
Reviewer: Sponsor: SponsorV

Description

Kathy and I are working on Moat client edge cases today :)
If a transport type that BridgeDB supports is requested and the correct CAPTCHA solution is provided in a /check request, the response is a moat-bridges response that includes an empty bridges array, like this:

{
  "data": [
    {
      "qrcode": null,
      "bridges": [],
      "version": "0.1.0",
      "type": "moat-bridges",
      "id": 3
    }
  ]
}

However, the Moat protocol spec says we will receive a 404 error response. Either response will do the job, but we need to make sure client and server are in agreement.

Child Tickets

Change History (5)

comment:1 Changed 11 months ago by isis

Thanks! I think the spec would probably be the better behaviour here? What do you think?

One quick question though: what if BridgeDB has 2 of the type requested, but not 3? (I.e. it's low on bridges) Should we just give the 2 that are useful and only return the JSON API 404 error if there's really no bridges at all?

comment:2 in reply to:  1 Changed 11 months ago by mcs

Replying to isis:

Thanks! I think the spec would probably be the better behaviour here? What do you think?

Probably. Returning an error in this case makes it 100% clear that the request could not be fulfilled.

One quick question though: what if BridgeDB has 2 of the type requested, but not 3? (I.e. it's low on bridges) Should we just give the 2 that are useful and only return the JSON API 404 error if there's really no bridges at all?

Is the Moat responder designed to return more than one bridge? The test server that Kathy and I compiled seems to always return just one. In fact, we currently have TODOs in the Tor Launcher code where we don't handle more than one bridge in the response (our code just grabs the first one in the array of returned bridges).

If BridgeDB is going to return more than one bridge, I think we should just spec the protocol to allow for fewer then 3 to be returned. In other words, it is better to get back one bridge than none.

comment:3 Changed 11 months ago by mcs

Parent ID: #24689

comment:4 Changed 11 months ago by isis

Keywords: bridgedb-moat bridgedb-distributors added
Points: 1
Priority: MediumImmediate
Resolution: fixed
Sponsor: SponsorV
Status: newclosed

Fixed in my fix/24637 branch, which includes the following small spec change specifying the error:

 If the ``SOLUTION`` was successful for the supplied ``CHALLENGE``, but the
 server is unable to distribute the requested Bridges, the server responds ``200
 OK`` with the following JSON::

     {
-      "error": {
-        "id": "1",
+      "errors": [{
+        "id": "6",
+        "type": "moat-bridges",
+        "version": "0.1.0",
         "code": "404",
         "status": "Not Found",
-        "title": "Could not fetch the type of bridges you requested",
         "detail": "DETAILS",
-      }
+      }]
     }

 where:

 * ``DETAILS`` is some string describing the detailed nature of the issue.

comment:5 in reply to:  4 Changed 11 months ago by mcs

Replying to isis:

Fixed in my fix/24637 branch, which includes the following small spec change specifying the error:
...

It looks like that branch has not been pushed to gitweb.tpo yet, although I see it on GitHub.

Note: See TracTickets for help on using tickets.