On 16/07/2015 09:53, Nicholas Alexander wrote: > On Wed, Jul 15, 2015 at 4:48 PM, Mark Hammond <[email protected] > <mailto:[email protected]>> wrote: > > On 16/07/2015 3:05 AM, Richard Newman wrote: > > It should boot other devices… but it will take several minutes > for them > to detect that they've been booted, because they have cached > tokens. If > it doesn't, and the other devices are still syncing an hour later > without complaint, then something very strange is happening. > > > FTR, I see Sync tokens being handed out with an hour validity, so it > is likely to take just under an hour before it *starts* failing - > ie, "several minutes" is probably too optimistic. > > FTR2: for the purposes of testing, creating a boolean pref > services.sync.debug.ignoreCachedAuthCredentials with a value of true > should force the failures to start immediately (but that obviously > will not reflect a typical user experience) > > FTR3: Fennec requests fresh tokenserver tokens every sync, so you should > be booted immediately from mobile. (This behaviour is actually not good > for traffic or battery life, but it's the current situation. Yay?)
FTR4: The time-to-revocation also depends on the behaviour of other clients in the cluster. If you change your password and then sync using the new password, tokenserver learns about the change and can boot out old clients after the 1-hour sync token expiry. If you change your password on the web but don't sync anything using the new password, then old devices can keep syncing until their FxA identity certificate expires. This could be up to *24 hours* in the case of a malicious client. Token expiry and revocation is hard. Ryan _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
