[lukevp]

We really shouldn't be writing our own authentication layers (or anything security-related for that matter) unless necessary.

Case in point, this example code has a massive security issue that allows anyone to impersonate without tokens if there is an active authentication request open. Hopefully no one has used this example code to build a production system that has real user data.

This is a perfect example of why this should really be part of CouchDB/PouchDB itself and not something each person must write themselves. This should be solved once, solved right, vetted by the community, and be easy to fall into a pit of success.

I really like CouchDB and PouchDB as a product, but this insistence that this is the right path is really holding you guys back.

[matlin]

You're probably write about writing your own authentication layer but it still shouldn't be part of CouchDB or PouchDB. A better solution is for some OSS project to build a standard proxy that applies the document level authorization that everyone is asking for. No reason for it to be built-in.

[lukevp]

I would agree if couchdb wasn't positioning itself as being exposed directly on the internet. If CouchDB is meant to be proxied behind another system / auth stack, then why does it have CORS support and cookie auth built in?

Both of those features are purely a client-side concern and exist because the original intent of CouchDB was real-time replication to browsers. Otherwise the proxy could do the CORS as well as the authentication and CouchDB would only require an http-level authentication pattern (like basic auth).

Having said that, I do agree that this should be compartmentalized and the end user should be able to pick and choose what features they want to allow, but I don't think that this should continue to be a separate concern that everyone is building themselves, it should be a first-party solution.