Confirmed users
385
edits
Services/Sync/SyncKey/J-PAKE/NewOrder: Difference between revisions
Jump to navigation
Jump to search
Services/Sync/SyncKey/J-PAKE/NewOrder (view source)
Revision as of 22:10, 29 August 2011
, 29 August 2011→UNFINISHED HERE--LAST SECTION--ALLY
| Line 212: | Line 212: | ||
== Detailed Flow == | == Detailed Flow == | ||
<ol> | <ol> | ||
| Line 219: | Line 217: | ||
<pre>C: GET /new_channel HTTP/1.1 | <pre>C: GET /new_channel HTTP/1.1 | ||
S: "a7id"</pre></li> | S: "a7id"</pre></li> | ||
<li>Mobile generates PIN from random weak secret (4 characters a-z0-9) and the channel ID, computes and uploads J-PAKE msg 1. | <li>Mobile generates PIN from random weak secret (4 characters a-z0-9) and the channel ID, computes and uploads J-PAKE msg 1.To prevent double uploads in case of retries, the If-None-Match: * header is specified. This makes sure that the message is only uploaded if the channel is empty. If it is not then the request will fail with a 412 Precondition Failed which should be considered the same as 200 OK. The 412 will also contain the Etag of the data was the client just uploaded. | ||
<b>New in version 3:</b> Timeouts will need to be increased to accommodate the case where users have to create an account on the Desktop before proceeding. | |||
<pre> | <pre> | ||
C: PUT /a7id HTTP/1.1 | C: PUT /a7id HTTP/1.1 | ||
| Line 270: | Line 267: | ||
</pre></li> | </pre></li> | ||
<li>Desktop computes and uploads msg 1. | <li>Desktop computes and uploads msg 1. The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200. | ||
<pre> | <pre> | ||
C: PUT /a7id HTTP/1.1 | C: PUT /a7id HTTP/1.1 | ||
| Line 322: | Line 317: | ||
... | ... | ||
</pre> | </pre> | ||
<p>Mobile computes and uploads msg 2. | <p>Mobile computes and uploads msg 2. The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200. | ||
</p> | </p> | ||
<pre>C: PUT /a7id HTTP/1.1 | <pre>C: PUT /a7id HTTP/1.1 | ||
| Line 360: | Line 353: | ||
... | ... | ||
</pre> | </pre> | ||
<p>Desktop computes key, computes and uploads msg 2. | <p>Desktop computes key, computes and uploads msg 2. The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200. | ||
</p> | </p> | ||
<pre> | <pre> | ||
| Line 432: | Line 423: | ||
... | ... | ||
</pre> | </pre> | ||
Desktop verifies it against its own version. If the hash matches, it encrypts and uploads Sync credentials. | Desktop verifies it against its own version. If the hash matches, it acquires (either the existing account or by creating a new one), then encrypts and uploads Sync credentials. | ||
The If-Match header is set so that we only upload this message if the other side's previous message is still in the channel. This is to prevent double PUTs during retries. If a 412 is received then it means that our first PUT was actually correctly received by the server and that the other side has already uploaded it's next message. So just consider the 412 to be a 200. | |||
<pre> | <pre> | ||
| Line 475: | Line 466: | ||
</pre> | </pre> | ||
<p>decrypts Sync credentials and verifies HMAC.</p></li> | <p>decrypts Sync credentials and verifies HMAC.</p></li> | ||
<pre> | <pre> | ||
C: DELETE /a7id HTTP/1.1 | C: DELETE /a7id HTTP/1.1 | ||
| Line 481: | Line 471: | ||
S: HTTP/1.1 200 OK | S: HTTP/1.1 200 OK | ||
... | ... | ||
</pre> | |||
</li> | |||
<li><b>New in version 3:</b> Desktop signals that uploading sync has finished | |||
<pre> | |||
C: PUT /a7id HTTP/1.1 | |||
C: If-Match: "etag-of-receiver4-message" | |||
C: | |||
C: { | |||
C: 'type': 'sender4', | |||
C: 'payload': { | |||
C: 'uploadTime': "base64encoded=", | |||
C: 'hasCompletedUpload': "bool=" | |||
C: } | |||
C: } | |||
Success response: | |||
S: HTTP/1.1 200 OK | |||
S: ETag: "etag-of-receiver4-message" | |||
</pre> | |||
</li> | |||
<li><b>New in version 3:</b> Mobile retrieves retrieves notice, starts downloading. Mobile kills the channel? Does it need a success response? | |||
<pre> | |||
C: GET /a7id HTTP/1.1 | |||
C: If-None-Match: "etag-of-receiver4-message" | |||
</pre> | </pre> | ||
</li> | </li> | ||