Time to declare 1.0 for TouchDB/iOS?

[Jens Alfke]

I’ve been checking in a few changes to trunk since the last beta, but none of them are things I feel comfortable putting into 1.0. I’m contemplating simply declaring victory and renaming 0.981 to 1.0 — the post-b8 stuff in trunk will then become part of an upcoming 1.0.1 release.

Does anyone have a problem with this? Know of any open bugs that absolutely need be fixed to consider TouchDB ready to be shrinkwrapped?

—Jens

[dyowee]

Hi sir Jens,

 

I'm still getting a 401 intermittently when running replication, but when I reboot the device, it seems to fix the issue.

 

Regards,

Joey
Noong Biyernes, Nobyembre 02 2012 02:30:50 UTC+8, si Jens Alfke ay sumulat:

[Jens Alfke]

On Nov 1, 2012, at 4:32 PM, dyowee <csharpen...@gmail.com> wrote:

I'm still getting a 401 intermittently when running replication, but when I reboot the device, it seems to fix the issue.

I haven’t seen a bug report of this…? (Please include log output.)

—Jens

[dyowee]

Ok sir, but it seems to replicate (from Cloudant) some of the documents, then after a while, it starts to log 401.

Noong Biyernes, Nobyembre 02 2012 07:42:28 UTC+8, si Jens Alfke ay sumulat:

[Jens Alfke]

On Nov 1, 2012, at 6:03 PM, dyowee <csharpen...@gmail.com> wrote:

Ok sir, but it seems to replicate (from Cloudant) some of the documents, then after a while, it starts to log 401.

This sounds very much like #175, which I think is fixed in the latest beta. Are you using that build?

If you’re on b8 (or a custom build that includes commit 354aa9c) and still having this problem, then as I said, file a bug report. It’s too hard to keep track of issues that get mentioned in emails; that’s what the Github bug tracker is for.

—Jens

[dyowee]

Sorry sir, will file a bug report. Yup, I'm using the latest beta.

Noong Biyernes, Nobyembre 02 2012 09:26:02 UTC+8, si Jens Alfke ay sumulat:

[dyowee]

I just have a question sir. Passing in the username in the url seems to fix the issue. Is that really a requirement when replicating?

 

Regards,

Joey
Noong Biyernes, Nobyembre 02 2012 09:26:02 UTC+8, si Jens Alfke ay sumulat:

[Jens Alfke]

On Nov 1, 2012, at 7:11 PM, dyowee <csharpen...@gmail.com> wrote:

I just have a question sir. Passing in the username in the url seems to fix the issue. Is that really a requirement when replicating?

Sometimes. If you’ve got two or more login credentials stored for that site in the NSURLCredentialStore, then if you don’t specify a username in the URL it’s not clear which one will be used. (The replicator asks for the ‘default’ one, but the NSURLCredentialStorage docs don’t say how the ‘default’ cred is picked.) If you have an obsolete credential in there, it might get used. That was behind the auth failures that Len Kawell was getting.

—Jens

[Jens Alfke]

On Nov 1, 2012, at 10:18 PM, dyowee <csharpen...@gmail.com> wrote:

Thanks sir. I really apologies for the trouble.

Oh, not at all. Thanks for testing this stuff out and helping make it solid.

I tried passing the username and password in the URL, and it seems to work best. Is that a secure way of replicating?

It doesn’t affect what goes over the network, so if you’re using SSL it’s still secure.

If this is a persistent replication, the URL is stored in the _replicator database, so it’s less secure on the device because the password is in an regular file. We discussed iOS filesystem encryption a while ago — IIRC, regular app files are still encrypted but not as securely as the Keychain is.

The most secure approach would be to put the username but not the password in the URL. Then use the NSURLCredentialStorage API to store the password persistently, which will put it in the Keychain. There’s sample code for that on the wiki.

—Jens

[dyowee]

Thanks sir! I'll keep on testing. Not sure if was just a Cloudant issue.
Noong Sabado, Nobyembre 03 2012 00:15:46 UTC+8, si Jens Alfke ay sumulat:

[Pulkit Singhal]

I think this is fine: