> On 09 May 2015, at 18:49, Tim Black <[email protected]> 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/
