[tor-bugs] #24433 [Obfuscation/BridgeDB]: moat isn't returning bridges on successful CAPTCHA completion

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Dec 13 18:35:01 UTC 2017


#24433: moat isn't returning bridges on successful CAPTCHA completion
----------------------------------+------------------------------
 Reporter:  isis                  |          Owner:  isis
     Type:  defect                |         Status:  needs_review
 Priority:  High                  |      Milestone:
Component:  Obfuscation/BridgeDB  |        Version:
 Severity:  Normal                |     Resolution:
 Keywords:  bridgedb-dist moat    |  Actual Points:  .5
Parent ID:                        |         Points:  1
 Reviewer:                        |        Sponsor:  SponsorM
----------------------------------+------------------------------

Comment (by isis):

 Replying to [comment:6 mcs]:
 > Kathy and I worked on integration some more and noticed the following
 issues (please let is know if you want us to open new tickets):

 Hi! Thanks for the review!

 > * The spec in README.rst needs to be updated. General issues are that
 single quotes should be replaced with double quotes and that all JSON
 values should be enclosed in quotes (e.g., the `id` value is not).

 Fixed in
 [https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=develop&id=8d8db4a06d3dff5e9f82adcb4e0e921fe3577098
 8d8db4a0]

 > * For the `/fetch` request, the `type` is specified as `moat-transports`
 but the implementation uses `client-transports`. For consistency with the
 other `type` values you may want to use `moat-transports`.

 [https://gitweb.torproject.org/user/isis/bridgedb.git/commit/?h=develop&id=50a9321fadcfd0e9a4f30bc1919c1bf46d27d8e1
 50a9321f]

 > * The `data` payload is specified as an object but the implementation
 uses an array. This is permitted by the JSON API specification but seems
 unnecessary for the moat protocol (since each request and response only
 includes one JSON object).

 We can change it back to a single object if you think that's better. My
 reasoning was:

 1. I totally read the spec wrong and I thought it said they had to be
 arrays, and
 2. future-compatibility, in case we decided at some point that providing
 the user with more messages/errors might be helpful (e.g. if there is some
 non-fatal error which we might want to return/log/display on the client-
 side, but we're still also going to return bridges/captchas).

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


More information about the tor-bugs mailing list