For migration to work correctly, we need to find the absolute URLs currently in the crypto records and make them relative. We actually need to do this in the client, because we are creating new users in PHX that have absolute URLs as well, and anyone who spins up a dormant instance of 1.3 or earlier will create new records that need fixing. So a one time-pass won't make users portable indefinitely.

This is something we need to do before we ship Fx4, but hopefully in 1.5.

If we want to specify that urls are always going to be relative, the client will still need to handle absolute urls at least for a few versions. Before the client can sync, it'll check the passphrase by getting pubkey/privkey and these existing records have absolute urls. Alternatively, if we wipe the server or move to a different "server storage version" 1.0 -> 1.1, we could just not migrate and there'll be a clean slate with no need to handle any absolute urls. The client will need to bump its storage version.. or at least should. Or maybe not if we just pretend the spec allows for both absolute and relative urls. The client would need to migrate old records from absolute to relative.

(In reply to comment #2) > If we want to specify that urls are always going to be relative, the client > will still need to handle absolute urls at least for a few versions. Yes, I don't see a reason not to support absolute URLs for a while or even indefinitely. > Before the client can sync, it'll check the passphrase by getting > pubkey/privkey and these existing records have absolute urls. Sure, but they're actually constructed from storageURL (see Weave.Service._updateCachedURLs) and not hardcoded somewhere. > Alternatively, if we wipe the server or move to a different "server storage > version" 1.0 -> 1.1, we could just not migrate and there'll be a clean slate > with no need to handle any absolute urls. > > The client will need to bump its storage version.. or at least should. Yes, we should bump the storage version as this clearly changes the (admittedly somewhat implicit) contract so far. Btw, I think we're at storage version 2 already, so that'd be 2.1 then I guess. > Or maybe not if we just pretend the spec allows for both absolute and relative > urls. The client would need to migrate old records from absolute to relative. Well, it wouldn't have to. AFAIK the server side migration script would convert absolute to relative URIs in the JSON records. OTOH, this wouldn't work for people who host their own server. But then again, their hosts might not change anyway.

(In reply to comment #3) > Yes, I don't see a reason not to support absolute URLs for a while or even > indefinitely. This means all other clients would have to support both instead of just relative urls. > Sure, but they're actually constructed from storageURL (see > Weave.Service._updateCachedURLs) and not hardcoded somewhere. Almost. ;) Seems like the common pattern of getting the private key is from the public key: PrivKeys.get(pubkey.privateKeyUri) But we could just fetch the private key directly.. > so that'd be 2.1 then I guess. The storage versions were decided to be integers, so we would be at 3. > Well, it wouldn't have to. AFAIK the server side migration script would convert > absolute to relative URIs in the JSON records. I suppose the migration script has already done this before to rewrite absolute urls, so rewriting to relative might not be too much more work.

Basic idea behind the patch is setting urls on properties like cryptowrapper.encryption and pubkey.privkeyuri and privkey.pubkeyuri will still take absolute uris but will convert it to a relative url spec using nsIURL.getRelativeSpec. To support that, one approach is to enforce that WBORecords always have a somewhat correct .uri/baseURI value. This means we need to make sure all the places we create records pass in the full absolute path up to the id. The existing code doesn't require id in the uri, but then id will need to be set on the record. One thing I haven't really examined is the CryptoMeta's js object hash of absolute uris -> encrypted symmetric key. We definitely want to support relative urls here. For the storage version, we'll want to bump it to prevent older clients from writing absolute urls. Officially, uris are "urls" in that they can be absolute urls or relative urls... Perhaps we should change the property name? But I haven't tested if old clients can read relative urls when checking the passphrase pubkey->privkeyUri...

Expands Mardak's WIP, make tests pass, adds tests for relative URI behaviour, bumps storage version.

Rebase v1 patch on latest fx-sync tip (make all tests pass again).

Unbitrod and split tests/test fixes into separate patch.

Tests and test fixes.

Fix up recently added tests for the tab store.

http://hg.mozilla.org/services/fx-sync/rev/36fd75f5f88b http://hg.mozilla.org/services/fx-sync/rev/c7a9509c5c29