On 23 Jul 2016 23:24, "Richard Newman" <[email protected]> wrote: > I suspect that you can ignore the details here, because you control neither > the IdP nor the consumer; just know that this can fail, and doing so implies > either bad input or a bug somewhere — see e.g., Bug 985504, Bug 1042109. > Prompt the user for their credentials again, and start over. > > The purpose of this whole flow is to make sure that clients with different > passwords (because you changed it on one device), and thus different keys, > don't sync to the same server and screw things up by seeing/writing partial > state. The purpose of the generation check is to avoid accidental time travel.
OK, I guess asking for the user's credentials again should do the trick. > You should read this. It's easier to understand the Java source than to > explain in English :) > > https://dxr.mozilla.org/mozilla-central/source/mobile/android/services/src/main/java/org/mozilla/gecko/sync/net/HawkAuthHeaderProvider.java I know how to generate a HAWK header. My problem was that I didn't know whether the id and key received from the tokenserver had to be base64 decoded before being passed to the HAWK header function. But, as I see here https://dxr.mozilla.org/mozilla-central/source/mobile/android/services/src/main/java/org/mozilla/gecko/tokenserver/TokenServerClient.java#231-235 and here https://dxr.mozilla.org/mozilla-central/source/mobile/android/services/src/main/java/org/mozilla/gecko/fxa/sync/FxAccountSyncAdapter.java#314 they appear to be passed directly as they are, without being decoded first, so this solves my problem. Thank you for your help! Regards, Gabriel _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
