Re: Accessing touchdb:/// from WebView on Android, or any other way of limiting access to the TouchDB contents from other apps/local network

[Jens Alfke]

On Nov 14, 2012, at 12:45 PM, Gina Cook <gina....@gmail.com> wrote:

Is TouchDB is still officially in admin party only?
This looks like we might not have to run admin party anymore:
https://github.com/couchbaselabs/TouchDB-iOS/commit/0235b18264f73ed14303ebf50e354f7aa7fd3ec0

Yes, the iOS/Mac code has some fairly simple authentication support. I don’t know if the equivalent has been added to Android yet.

What we want to work:

* this.mInitialAppServerUrl = "touchdb:///mydbname/_design/pages/where.html”;

I’m not sure what you mean by “work” in this context. If you mean “require valid credentials to access”, I think the answer is that it doesn't work. The custom URL scheme is the app's direct internal interface to TouchDB; it has no authentication. It’s the TDListener layer, the one that actually accepts incoming HTTP connections, that does authentication.

(However, things may be different on Android, so take this with a grain of salt. Marty would know best.)

What’s the big picture — what is your app doing that makes you worry about auth?

—Jens

[Gina Cook]

Hi Jens, 

On Wednesday, November 14, 2012 3:56:22 PM UTC-5, Jens Alfke wrote:

On Nov 14, 2012, at 12:45 PM, Gina Cook <gina....@gmail.com> wrote:

Is TouchDB is still officially in admin party only?
This looks like we might not have to run admin party anymore:
https://github.com/couchbaselabs/TouchDB-iOS/commit/0235b18264f73ed14303ebf50e354f7aa7fd3ec0

Yes, the iOS/Mac code has some fairly simple authentication support. I don’t know if the equivalent has been added to Android yet.

I'm pretty sure the iOS/Mac code isnt in the Android side yet for the TDListener. The good news is that Android is what I do everyday, so I can probably help if that's what we need to do to lock down our TouchDB. 

What we want to work:

* this.mInitialAppServerUrl = "touchdb:///mydbname/_design/pages/where.html”;

I’m not sure what you mean by “work” in this context. If you mean “require valid credentials to access”, I think the answer is that it doesn't work. The custom URL scheme is the app's direct internal interface to TouchDB; it has no authentication. It’s the TDListener layer, the one that actually accepts incoming HTTP connections, that does authentication.

(However, things may be different on Android, so take this with a grain of salt. Marty would know best.)

By work I actually mean't anything, credentials or not. If we hit that url (and any of the other variations we have tried because we dont actually know what the url would be) in a WebView it says "Webpage not available." If we can load touchdb:/// in the WebView internal to our app, we wouldn't mind the credentials problem because at least it is our process who is loading the touchdb: url, not another process or another computer on the local network. 

I would consider the credentials problem solved well enough for us, if we could just load the touchdb:/// url in a WebView. I see reference to touchdb: in many places on the web, but no examples talk about specifically using it in an Android WebView. It seems like everyone is using TouchDB for native apps, no HTML5 apps. I can also see a pretty clear workaround in the Ektorp replication activity put in specifically to make it possible to resolve it:

// static inializer to ensure that touchdb:// URLs are handled properly
{
TDURLStreamHandlerFactory.registerSelfIgnoreError();

}

What’s the big picture — what is your app doing that makes you worry about auth?

 

We are an open source fieldlinguistics company which makes experimentation/data collection apps for researchers at McGill and Universite de Montreal which they can take into the field, or into an elementary school or basement where there is often no wifi. In order to get ethics board approval they are required to keep human subjects data confidential. Even though the likelihood of another app on the Android or on the local network having access to our TouchDB is minimal, we are required by law to protect the data... We have used a couple of solutions to move data between an Android and server before, but we were hoping to switch to TouchDB since we like Couch. Here is our GitHub HTML/Android repo which we are building out to use Touchdb for syncing the data :)

https://github.com/iLanguage/OPrime/blob/master/AndroidHTML5OfflineLib/src/ca/ilanguage/oprime/activity/HTML5ReplicatingActivity.java

I have a pretty strong feeling that we just aren't going to get URLs like touchdb:///mydbname/_design/pages/where.html to load in an Android WebView. Maybe its the wrong URL.. we have tried every combination from what we see in the google group in the issue tracker and on stack overflow,  or maybe its Android blocking non-[http, https, file] protocols... or maybe our WebView isn't "internal" enough to the app to be able to get a response from Ektorp... 

—Jens

[Jens Alfke]

On Nov 14, 2012, at 2:16 PM, Gina Cook <gina....@gmail.com> wrote:

> I'm pretty sure the iOS/Mac code isnt in the Android side yet for the TDListener. The good news is that Android is what I do everyday, so I can probably help if that's what we need to do to lock down our TouchDB.

That would be great — the Android version could use some attention.

> By work I actually mean't anything, credentials or not. If we hit that url (and any of the other variations we have tried because we dont actually know what the url would be) in a WebView it says "Webpage not available." If we can load touchdb:/// in the WebView internal to our app, we wouldn't mind the credentials problem because at least it is our process who is loading the touchdb: url, not another process or another computer on the local network.

Ah, I see. I’m afraid I don’t know enough about the internals of how TouchDB/Android communicates with Ektorp. On iOS it registers an NSURLProtocol to handle ‘touchdb:’ URLs, and that’s visible to WebKit as well as Cocoa apps because both use NSURLConnection for URL requests.

I’m not sure whether Android/Java has a similar mechanism, or whether TouchDB there has to use the less desirable approach of opening a real TCP listener on the loopback interface. In the latter case, adding HTTP auth would still be feasible — a password could be generated at random at startup time and made available through an in-process API.

As I’ve said before, I believe Marty is going to have more time to devote to TouchDB soon, but right now we’re still in the final throes of completing Couchbase Server 2.

—Jens

[Gina Cook]

Thanks Jens,

I'll do our encryption of attachments first, see if I can get that to flow, get comfortable with TouchDB then I will start looking at your suggestions. 

I made an issue for anyone else who finds this thread later and wonders what was the result. https://github.com/iLanguage/OPrime/issues/1

[Alexander Gabriel]

Hi Gina

Would be great to hear how you got a CouchApp to work out of TouchDB.

Alex

--
 
 

--

 

***********************************************************

 

Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64
al...@barbalex.ch
www.barbalex.ch

[Gina Cook]

Hallo Alex,

It was super simple, we took the Android Grocery Sync replication
code, had it continuously replicate the couchapp, added a TDListener
when the App starts, and then passed the localhost url to the WebView.
We used couchapp to create and deploy the couchapp to iriscouch.
https://github.com/couchapp/couchapp

Are you using Android or iOS? If Android I can give you more specific
instructions...

> --
>
>

[Alexander Gabriel]

so simple?

Wow, what a great technology!

I haven't ventured into iOs or Android very seriously yet. I have an almost finished couchapp. Knowing that this is possible I only need some free time (it's a hobby project) and tackle setting up syncpoint (and for that an own web-server) to try it out.

Thanks so much for this advice.

Alex

 

***********************************************************

 

Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64
al...@barbalex.ch
www.barbalex.ch

2012/11/15 Gina Cook <gina....@gmail.com>

--