Re: Two names: CouchDB & Couch App Server

[Giovanni Lenzi <g....@smileupps.com>]

Hi Tim,

due to some bug I'm unable to log in at
> http://chatty-379423-frontend1.smileupps.com/ to test whether this is
> the case per
>
> http://couchdb.markmail.org/search/?q=How+do+CouchApps+fit+into+the+CouchDB+story%3F+%28Was%3A+CouchDB+Articles+Pills+and+Tutorials+Ideas%29+order%3Adate-backward#query:How%20do%20CouchApps%20fit%20into%20the%20CouchDB%20story%3F%20(Was%3A%20CouchDB%20Articles%20Pills%20and%20Tutorials%20Ideas)%20order%3Adate-backward+page:5+mid:h5dmp7dt7xhhoa7z+state:results
> ),


Can't understand... Do you get some errors? If you are trying to login to
frontend1 with "chatty" username, then an error is the intended chatty
behaviour, because he is granted on admin UI domain only(even if you can
relax this by modifying chatty ddoc). If you have more feedback about this,
I think we can talk privately, to not bore others.


> then *make a config option to make CouchDB require the Host header*.  It
> sounds easy to do, and the Host header is required in HTTP 1.1.  Or
> create a "default _rewrite path" configuration parameter as Giovanni
> described.  I expect this would make SmileUpps' CouchApp architecture
> secure for anyone who wants to use that architecture.
>
SmileUpps' CouchApp architecture
> is the only CouchApp architecture I'm aware of which has (almost)
> implemented document-level ACLs without some proxy server between the
> browser and CouchDB.


Ok, just want to be sure here, we are talking of same things. You are
referring to Smileupps way of writing apps here, right? Because Smileupps
"infrastructure" instead, heavily relies on proxies, so as far as we
thought it correctly, it shouldn't have such of these security concerns.
Otherwise I would really appreciate, if you could share, with us, these
kind of security concerns confidentially. :-)


> It seems to me a developer should learn Backbone
> or Angular before CouchApps (like the Chatty tutorial assumes:
> https://www.smileupps.com/couchapp-tutorial-chatty-read-api).

So,
> because they generally require 1) knowledge of a client-side framework,
> 2)  knowledge of CouchApps' file structure and functionality, and 3)
> implementing a very specific CouchApp configuration to be properly
> secured, CouchApps aren't really an entry point into web development.
> Instead, *CouchApps are **a way for non-novice developers to use CouchDB
> as both a database and an app server.*
>
>
Exactly! you are right. Our tutorial assumes Angular... and, of course, it
may not be exactly a tutorial for beginners... And maybe, we assumed many
other things a beginner probably doesn't get. But we started, just from
that kind of tutorial, to show how a non-novice developer can benefit of
couchdb awesome features and how he can do it safely.

I think too that tutorials for beginners, using plain javascript only, or
other frameworks are surely something the community could be interested to
help with.


>  Web apps don't live on the server anymore.  They live in your phone.


Until today, I never really understood how security could be really
implemented client-side only... I always imagined this kind of apps to be
more consumer-oriented, where security is not such a big concern, but not
for companies. Do you have some pointers talking about "offline-first and
nobackend security"? Thanks in advance.


6.  Market an accurate Venn diagram.
> 7.  My proposal.
>

Wow, this is a very deep and enlightening analysis!!!
I agree on all what you said and with the proposal.


-- 
Giovanni Lenzi
www.smileupps.com
Smileupps Cloud App Store

Re: Two names: CouchDB & Couch App Server

[Jan Lehnardt <ja...@apache.org>]

> On 09 May 2015, at 18:49, Tim Black <ti...@alwaysreformed.com> wrote:
> 
> Hi Giovanni,
> 
> On 05/09/2015 03:44 AM, Giovanni Lenzi wrote:
>> due to some bug I'm unable to log in at
>>> http://chatty-379423-frontend1.smileupps.com/ to test whether this is
>>> the case per
>>> 
>>> http://couchdb.markmail.org/search/?q=How+do+CouchApps+fit+into+the+CouchDB+story%3F+%28Was%3A+CouchDB+Articles+Pills+and+Tutorials+Ideas%29+order%3Adate-backward#query:How%20do%20CouchApps%20fit%20into%20the%20CouchDB%20story%3F%20(Was%3A%20CouchDB%20Articles%20Pills%20and%20Tutorials%20Ideas)%20order%3Adate-backward+page:5+mid:h5dmp7dt7xhhoa7z+state:results
>>> ),
>> 
>> Can't understand... Do you get some errors? If you are trying to login to
>> frontend1 with "chatty" username, then an error is the intended chatty
>> behaviour, because he is granted on admin UI domain only(even if you can
>> relax this by modifying chatty ddoc).
> I'm sorry, I made a dumb mistake.  I failed to follow this instruction
> which you gave plainly on the site:  "use dashboard to create users
> credentials and their profiles first!"  So there is no bug.  I'm sorry I
> assumed it was a bug.
> 
> I sent a request without the Host header (using a Chrome extension which
> permits that) and wasn't able to get any user data other than my own.  I
> wasn't able to guess the correct database name to use in the query.  I
> didn't read the code exhaustively to see if there was a place I could
> set a breakpoint maybe and find the database name.  But if I was able to
> discover that database name through the frontend, could I get other
> users' data?
>> 
>> 
>>> then *make a config option to make CouchDB require the Host header*.  It
>>> sounds easy to do, and the Host header is required in HTTP 1.1.  Or
>>> create a "default _rewrite path" configuration parameter as Giovanni
>>> described.  I expect this would make SmileUpps' CouchApp architecture
>>> secure for anyone who wants to use that architecture.
>>> 
>> SmileUpps' CouchApp architecture
>>> is the only CouchApp architecture I'm aware of which has (almost)
>>> implemented document-level ACLs without some proxy server between the
>>> browser and CouchDB.
>> 
>> Ok, just want to be sure here, we are talking of same things. You are
>> referring to Smileupps way of writing apps here, right?
> I thought so, but am probably mistaken.  We humans are plagued by
> ignorance and error.  I was going on what I've read of the Chatty
> CouchApp tutorial.  I had not carefully read other things on your site
> which may mention the use of proxies.
>> Because Smileupps
>> "infrastructure" instead, heavily relies on proxies, so as far as we
>> thought it correctly, it shouldn't have such of these security concerns.
> Does Smileupps' security start in the proxies, or in CouchDB?  I thought
> there was a disagreement in this thread over whether CouchApps could be
> secured sufficiently in CouchDB alone without a proxy.

I’m confused here, too :)

Given that a proxy enforces the Host: header, how do you solve the problem
of multiple users per DB with different doc visibilities and view results
that could include data from other docs (e.g. _sum) that you weren’t
supposed to read in the first place?

The options are:
 - block views in the proxy, but I doubt you are doing this?
 - implement custom view server that creates Users x Views indexes and a
   proxy that does the correct routing.

Best
Jan
--


>> Otherwise I would really appreciate, if you could share, with us, these
>> kind of security concerns confidentially. :-)
> I agree that people shouldn't post security exploits publicly, but
> rather send them to you privately.
>>> Web apps don't live on the server anymore.  They live in your phone.
>> 
>> Until today, I never really understood how security could be really
>> implemented client-side only... I always imagined this kind of apps to be
>> more consumer-oriented, where security is not such a big concern, but not
>> for companies. Do you have some pointers talking about "offline-first and
>> nobackend security"? Thanks in advance.
> I'm not any kind of authority on those things, sorry.  Hoodie's
> one-database-per-user approach permits a user to access only that data
> which filtered replications let into his own database, so presently I'm
> attempting to follow that method of implementing security/ACLs, but
> Hoodie is a backend.  I think maybe something like PGP would work for
> allowing security to be governed from the client side completely.  But
> PGP's always had trouble achieving adoption among ordinary nontechnical
> users, so I don't know whether it could be made accessible in a true
> peer-to-peer social network like Monocles (which also was still written
> to require a relatively persistent server; I'd like to see one written
> which doesn't require a server very often, or, in other words, which
> puts the server in the browser, and maintains a list of active known
> peers which all network with each other, more like Bittorrent; nearly
> like http://vole.cc/.  Wuala's encryption tree would be an interesting
> model to follow).
> 
> Tim
> 

-- 
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/

Re: Two names: CouchDB & Couch App Server

[Tim Black <ti...@alwaysreformed.com>]

Hi Giovanni,

On 05/09/2015 03:44 AM, Giovanni Lenzi wrote:
> due to some bug I'm unable to log in at
>> http://chatty-379423-frontend1.smileupps.com/ to test whether this is
>> the case per
>>
>> http://couchdb.markmail.org/search/?q=How+do+CouchApps+fit+into+the+CouchDB+story%3F+%28Was%3A+CouchDB+Articles+Pills+and+Tutorials+Ideas%29+order%3Adate-backward#query:How%20do%20CouchApps%20fit%20into%20the%20CouchDB%20story%3F%20(Was%3A%20CouchDB%20Articles%20Pills%20and%20Tutorials%20Ideas)%20order%3Adate-backward+page:5+mid:h5dmp7dt7xhhoa7z+state:results
>> ),
>
> Can't understand... Do you get some errors? If you are trying to login to
> frontend1 with "chatty" username, then an error is the intended chatty
> behaviour, because he is granted on admin UI domain only(even if you can
> relax this by modifying chatty ddoc).
I'm sorry, I made a dumb mistake.  I failed to follow this instruction
which you gave plainly on the site:  "use dashboard to create users
credentials and their profiles first!"  So there is no bug.  I'm sorry I
assumed it was a bug.

I sent a request without the Host header (using a Chrome extension which
permits that) and wasn't able to get any user data other than my own.  I
wasn't able to guess the correct database name to use in the query.  I
didn't read the code exhaustively to see if there was a place I could
set a breakpoint maybe and find the database name.  But if I was able to
discover that database name through the frontend, could I get other
users' data?
>
>
>> then *make a config option to make CouchDB require the Host header*.  It
>> sounds easy to do, and the Host header is required in HTTP 1.1.  Or
>> create a "default _rewrite path" configuration parameter as Giovanni
>> described.  I expect this would make SmileUpps' CouchApp architecture
>> secure for anyone who wants to use that architecture.
>>
> SmileUpps' CouchApp architecture
>> is the only CouchApp architecture I'm aware of which has (almost)
>> implemented document-level ACLs without some proxy server between the
>> browser and CouchDB.
>
> Ok, just want to be sure here, we are talking of same things. You are
> referring to Smileupps way of writing apps here, right?
I thought so, but am probably mistaken.  We humans are plagued by
ignorance and error.  I was going on what I've read of the Chatty
CouchApp tutorial.  I had not carefully read other things on your site
which may mention the use of proxies.
>  Because Smileupps
> "infrastructure" instead, heavily relies on proxies, so as far as we
> thought it correctly, it shouldn't have such of these security concerns.
Does Smileupps' security start in the proxies, or in CouchDB?  I thought
there was a disagreement in this thread over whether CouchApps could be
secured sufficiently in CouchDB alone without a proxy.
> Otherwise I would really appreciate, if you could share, with us, these
> kind of security concerns confidentially. :-)
I agree that people shouldn't post security exploits publicly, but
rather send them to you privately.
>>  Web apps don't live on the server anymore.  They live in your phone.
>
> Until today, I never really understood how security could be really
> implemented client-side only... I always imagined this kind of apps to be
> more consumer-oriented, where security is not such a big concern, but not
> for companies. Do you have some pointers talking about "offline-first and
> nobackend security"? Thanks in advance.
I'm not any kind of authority on those things, sorry.  Hoodie's
one-database-per-user approach permits a user to access only that data
which filtered replications let into his own database, so presently I'm
attempting to follow that method of implementing security/ACLs, but
Hoodie is a backend.  I think maybe something like PGP would work for
allowing security to be governed from the client side completely.  But
PGP's always had trouble achieving adoption among ordinary nontechnical
users, so I don't know whether it could be made accessible in a true
peer-to-peer social network like Monocles (which also was still written
to require a relatively persistent server; I'd like to see one written
which doesn't require a server very often, or, in other words, which
puts the server in the browser, and maintains a list of active known
peers which all network with each other, more like Bittorrent; nearly
like http://vole.cc/.  Wuala's encryption tree would be an interesting
model to follow).

Tim