Aha, there was a bug in the test-moat script, because the server requires (in order to create and check the CAPTCHA) that it has some notion of what the client's IP is. Added an "X-Forwarded-For" header to the curl command fixed it. I've also made it somewhat easier to pass the latest challenge and the solution (always "Tvx74PMy" since that's the only CAPTCHA in the bridgedb.git/captchas directory):
Actually, heh. From the above output, there's another bug (although it shouldn't stop testing). It's giving a QR when we said we didn't need one. I guess it's nice to know the server is enthusiastic about sending images anyway (and that it works). I've made #24443 (moved) for that.
It looks like this is working when I use the test-moat script now. Yay!
I assume that "X-Forwarded-For" will be automatically inserted by the front server. For now, to proceed with integration, we can add it manually like you did in test-moat.
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):
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).
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.
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).
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).
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.
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:
I totally read the spec wrong and I thought it said they had to be arrays, and
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).
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.
Oops, I believe the original behaviour was actually correct: the client, when requesting /fetch, sends a "type": "client-transports". The server, when responding to that request, iff there was no overlap in which transports are supported, sends "type": "moat-transports" to let the client software know which types it does have available.
I've reverted 50a9321f.
Closing as fixed; fingers crossed nothing else is broken.
Trac: Actualpoints: .5 to 1 Status: needs_review to closed Resolution: N/Ato fixed
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:
I totally read the spec wrong and I thought it said they had to be arrays, and
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).
My argument is that using arrays just makes the code a little more complicated, and on the client side we are always going to send a one-element array for requests and we are going to use data[0] when handling each response. But let's just use arrays since that is what is already implemented.
Oops, I believe the original behaviour was actually correct: the client, when requesting /fetch, sends a "type": "client-transports". The server, when responding to that request, iff there was no overlap in which transports are supported, sends "type": "moat-transports" to let the client software know which types it does have available.