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
