Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for _session and cookies in couchbase-lite-ios #133

Closed
wants to merge 10 commits into from

Conversation

jeffrafter
Copy link

We are currently working to get _session support in couchbase-lite. It is probably not ready to go yet, but it is working for us with simple authentication. I know that _session support was explicitly skipped, but I wondered if having code would change that. The code is similar in nature to the erlang (which I used as a basis) but there is not yet support for pbkdf2 passwords. Comments on this are very welcome.

NOTE: This branch has a couple of project fixes in it too so that it can run as a subproject but I don't know that those should be part of this PR.

@snej
Copy link
Contributor

snej commented Sep 26, 2013

Could you explain what this is for? I can't think of a real use for this, since the replicator doesn't use sessions to log in, and an internal client (i.e. a PhoneGap type app) doesn't need to authenticate at all.

@jeffrafter
Copy link
Author

In our case the app is an HTML5/JavaScript app (PhoneGap) style that uses log ins on a set of peer machines. Having login allows us to tie specific user actions to specific records from the web client (i.e., user1 is logged in a recorded the following data). Even though these are individual devices they have many users (at different times or on different days) and the users are replicated with the data. We have used the session functionality to make this happen.

@ghost ghost assigned waynecarter Oct 17, 2013
@jchris
Copy link
Contributor

jchris commented Nov 16, 2013

May I suggest an alternative approach of managing the sessions at the application layer:

Keep a database per user on the local device, and ensure your application can is only working with the appropriate database for which user is logged in. If there are large amounts of shared data then you can put it on a shared database but that will get tricky if there are edits to the shared database.

Basically you want each user to push to the source only their personal database. Or maybe the shared database and the personal database can even push to the same source. But for user-specific data, you only want to push it upstream, as the user who owns it.

@snej
Copy link
Contributor

snej commented Sep 12, 2014

I still don't see a practical use for this. An app can do authentication at the UI level, if it needs to support multiple users. We don't need to turn CBL into a multi-user database.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants