[tor-bugs] #23136 [Applications/Tor Launcher]: moat integration (fetch bridges for the user)

[Tor Bug Tracker & Wiki]

#23136: moat integration (fetch bridges for the user)
--------------------------------------------+------------------------------
 Reporter:  mcs                             |          Owner:  brade
     Type:  defect                          |         Status:  needs_review
 Priority:  Very High                       |      Milestone:
Component:  Applications/Tor Launcher       |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  TorBrowserTeam201802R, ux-team  |  Actual Points:
Parent ID:  #24689                          |         Points:
 Reviewer:                                  |        Sponsor:  Sponsor4
--------------------------------------------+------------------------------

Comment (by brade):

 Replying to [comment:63 gk]:
 > Here comes another round:
 >
 > 11) "We allow response.data to be an array or object". What about
 > `response.errors`?

 The JSON API spec says that `errors` must be an array but `data` does not
 have to be an array (see http://jsonapi.org/format/#document-top-level).
 Isis implemented the `data` payload as an array, but we wanted to be
 robust and allow it to be an object (we can remove that code if you want
 us to do so; for a long time we did not have a server to talk to ;)

 > 12) Spec says 'error', yet we check for `response.errors`, typo?

 That was a typo in the spec which Isis has fixed.

 > 13) braces mix
 > ...

 We will fix this.

 > 14)  // Returns a promise that is fulfilled with an object that
 contains:
 >      // captchaImage
 >
 > Do you mean "image" here instead of "captchaImage"? I looked at the spec
 and thought this was another instance of the spec you linked to being
 outdated but then I saw `image` in `_parseFetchResponse()`. If so, could
 you order the attributes in the comment lines: `transport`, `image`, and
 `challenge` as outlined in the spec?

 Our code actually transforms `image` in the Moat response to
 `captchaImage` in the JS object that is created and returned. It was
 clearer to us to use a more descriptive name.  We will reorder the
 property names in the comment.

 >
 > 15)
 >
 > {{{
 >      * If there is no overlap between the type of bridge we requested
 and
 >      * the transports which BridgeDB supports, the response is the same
 except
 >      * the transport property will contain an array of supported
 transports:
 >      *     ...
 >      *     "transport": [ "TRANSPORT", "TRANSPORT", ... ],
 > }}}
 >
 > Really? The spec seems to say
 > ...

 This was a spec change that came about during some conversations we had
 with Isis. The comment we have is correct based on the current spec.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23136#comment:66>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online