colinskow / superlogin

Powerful authentication for APIs and single page apps using the CouchDB ecosystem which supports a variety of providers.
MIT License
371 stars 117 forks source link

couchbase sync_gateway or .. #170

Open iamdanthedev opened 7 years ago

iamdanthedev commented 7 years ago

Hi

This is a question: before digging into superlogin sources, can anyone tell me if this is conceptually possible to make superlogin work with sync_gateway? Sync_gateway is a couchdb protocol compliant proxy, which sits in between your couchbase and your clients (of which pouchdb is one example) and routes the data. One of the benefits, you can drop the 'one db per user' approach, as sync_gateway will route documents to channels, which are accessible by roles and users.

Sync_gateway exposes separate admin api, which allows to register and authenticate users on it. Authenticating produces a session id, which you can be set as a cookie on your client and therefore on connections from client's pouchdb sync_gateway will enforce read and write rules.

Does anyone have experience in coupling them?

MauroJr commented 7 years ago

I wish to know this too... anyone can help with this?

fredericgermain commented 7 years ago

I made a port on sync_gateway

It needs some patch on sync_gateway (mostly on the view api) Also, I change superlogin to use sync_gateway natively, instead of the "hack" used by the implementation on couchdb. sync_gateway session are stateful, so we can delete them (I believe it's more complicated on couchdb where you cannot simply DELETE session are they are stateless).

The security model is quite different, I'm still playing with my implementation. That's why I don't try to do a pull request yet.

But it's open to discussion.

You can find it here for now : https://github.com/fredericgermain/superlogin/tree/couchbase-syncgateway

clariontools commented 7 years ago

@fredericgermain - I also looked at this and as you say the security model is stateful so that is a big difference in the implementation. The reason I gave up was because it appears that couchbase is moving to the beat of a different drummer, in particular:

The new protocol is incompatible with version 1.x, and with CouchDB-based databases including PouchDB and Cloudant. Since Couchbase Lite 2 developer builds support only the new protocol, to test replication you will need to run the corresponding developer build of Sync Gateway, which supports both.

So my guess is that at some point with couchbase lite 2.0 there may be a new Sync Gateway that does not support the old protocol. The main concern is replication with PouchDB in my case and I am not sure that it would be supported going forward and it seems a bit risky as couchbase is a different animal and seems to like it that way :zap:

The other thing I was considering with sync gateway was trying to map the private user db concept of CouchDB to channels in couchbase, have you considered that?

fredericgermain commented 7 years ago

Hi,

Yes, I'm still unsure what the couchbase team has in mind for their product. I'm not into their couchbase mobile stack, I'm all react/react naive, so all I need is a JS/HTML5 stack like PouchDB, which they don't provide. That's why I want to keep my options open by using at least PouchDB with sync gateway.

I like superlogin architecture to store user by their social account and the ability to link/unlink acounts. I want to have something similar to firebase auth.

I still haven't had much time to plays around authorization goodies. But as the channel concept of sync-gateway seems more powerful than the user database of couchdb, I wanted to use channel directly in sync-gateway. To keep compatibility with couchdb, I'll try to design so that it's compatible with the cheap user couchdb databases. It's not in a so high priority in my project, as I'm using Firebase auth right now.

But I'll try to share when I have some progress!

clariontools commented 7 years ago

@fredericgermain - Looks like you are making some good progress already. When I was looking at sync gateway, I was only interested in using it to aggregate data with a couchbase backing. The benefits of using couchbase vs. couchdb for my use case would be access to an ODBC driver, the N1QL (SQL like query language), all for the benefit of aggregating data, administrative, reporting, analytics, on the backend. However, as I recall with sync gateway and couchbase it was a one way street, that is, if you hit couchbase server directly (not through sync gateway), the sync gateway and the mobile clients would know nothing of those changes. That problem, where direct couchbase updates don't directly update though sync gateway, lessened the excitement for using a couchbase backing in the mix.

It has been a while since I dropped sync gateway in favor of superlogin <-> couchdb/pouchdb. If you are looking to back sync gateway with couchdb, I am curious what are the benefits of having sync gateway in the middle?

MauroJr commented 6 years ago

@clariontools - The existing Sync Gateway REST endpoint that is compatible with the CouchDB API will continue to be supported in Sync Gateway 2.0. All existing applications can continue to use the current REST API to replicate to Sync Gateway 2.0.

And also after the Sync Gateway 1.5 Mobile and Couchbase Server 5.0, web and desktop applications can write to the same bucket in a Couchbase cluster. In this release, the metadata created by Sync Gateway, to facilitate replication between occasionally connected or disconnected edge devices and the cloud, is abstracted from applications reading and writing data directly to Couchbase Server.

In other words, the updates made directly in the Couchbase (not through sync gateway), is now replicated to PouchDB.

clariontools commented 6 years ago

@MauroJr - What you described sounds like it is worth another look. Based on what you say:

updates made directly in the Couchbase (not through sync gateway), is now replicated to PouchDB.

It sounds like you could completely eliminate the need for sync gateway if you have a mobile client (or web app) that uses PouchDB for local storage? That would then make Couchbase more like CouchDB with its integrated REST api? Is this the case or are there limitations, performance, and/or security issues?

MauroJr commented 6 years ago

@clariontools - Sorry, maybe I didn't describe this clearly enough... Actually, updates made directly in the Couchbase (not through sync gateway), is now replicated to PouchDB (through sync gateway).

Before Sync Gateway 1.5 that wasn't possible, the updates made directly to Couchbase wasn't propagated to Sync Gateway, even so, was not possible to use the same Bucket.

Now you can use the same Bucket for your server application to make updates via the SDK, and for PouchDB make it via Sync Gateway, and the documents are replicated to both sides.

clariontools commented 6 years ago

@MauroJr - Thanks for the extra info, that is a great feature (1.5 Sync Gateway participation with direct writes to Couchbase) will have to test it out.