You might want to look into using PouchDB with the User authentication plugin for PouchDB and CouchDB. That’s really a pretty great option and offers a lot more that can make your development easier.
https://pouchdb.com https://github.com/nolanlawson/pouchdb-authentication Kindest Regards, Bill Stephenson Tech Support www.ezInvoice.com <http://www.ezinvoice.com/> 1-417-546-8390 > On Dec 5, 2016, at 5:30 AM, Nicholas Outram <[email protected]> > wrote: > > Hi > > Thanks Martin. I’ll take a look at those links. > > I’ve since understood that the CouchDB users are to authenticate at database > level, and not document (which is fine, as long as I know). Right now the > option I’m considering is to use Kituta and create a middleware layer to > abstract away the creation of users and authentication, plus perform the > hashing of passwords etc.. Not sure where this leaves me with "Offline First”. > > Nick > > > > > On 5 Dec 2016, at 09:49, Martin Broerse > <[email protected]<mailto:[email protected]>> wrote: > > Hi Nick, > > You can use https://github.com/gr2m/couchdb-user-management-app to create > users. We use https://github.com/martinic/ember-simple-auth-pouch to auth > users without middleware. Example: https://bloggr.exmer.com/ ( > https://github.com/broerse/ember-cli-blog ) > We still need something for password reset but are trying to solve this > last part with OpenWhisk. > > - Martin > > > On Mon, Dec 5, 2016 at 10:05 AM, Nicholas Outram < > [email protected]<mailto:[email protected]>> wrote: > > I’m new to CouchDB, and much more accustomed to relational databases, so > please excuse any naivety in this question. > > I’m going to dive right in a build an iOS app using CouchDB instead of > iCloud, but before I do so, I’d just like to clarify a few fundamentals if > I may: > > The app is a simple idea, designed to help management of large classes in > University: > > A tutor creates a classroom session with a unique session id; students > sign in and join the session using the session id; when students have a > question, they tap a button (join the queue) - the teacher(s) can then help > students in order (so it’s fair etc..). > > 1. I'm assuming the client app will connect directly to CouchDB, as there > is little motivation to write any middleware - unless I’m missing something > here? > > 2. What is the best practise for managing users and sign-in? There is the > notion of ‘users’ in couch, but I’m unclear where they fit into the greater > scheme of things. For a traditional middleware + SQL server, there would > typically be one database user with imposed limited privileges (for > security, no drop table etc..), and end-user credentials would be hashed > and stored in tables by the middleware. Is the model similar in CouchDB, or > more fluid? I could also use client side encryption and store student > credentials in a single document (as described in the Wiki). > > May thanks in advance, > > > Nick > > ________________________________ > [http://www.plymouth.ac.uk/images/email_footer.gif]<http: > //www.plymouth.ac.uk/worldclass<http://www.plymouth.ac.uk/worldclass>> > > This email and any files with it are confidential and intended solely for > the use of the recipient to whom it is addressed. If you are not the > intended recipient then copying, distribution or other use of the > information contained is strictly prohibited and you should not rely on it. > If you have received this email in error please let the sender know > immediately and delete it from your system(s). Internet emails are not > necessarily secure. While we take every care, Plymouth University accepts > no responsibility for viruses and it is your responsibility to scan emails > and their attachments. Plymouth University does not accept responsibility > for any changes made after it was sent. Nothing in this email or its > attachments constitutes an order for goods or services unless accompanied > by an official order form. > > > ________________________________ > [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> > > This email and any files with it are confidential and intended solely for the > use of the recipient to whom it is addressed. If you are not the intended > recipient then copying, distribution or other use of the information > contained is strictly prohibited and you should not rely on it. If you have > received this email in error please let the sender know immediately and > delete it from your system(s). Internet emails are not necessarily secure. > While we take every care, Plymouth University accepts no responsibility for > viruses and it is your responsibility to scan emails and their attachments. > Plymouth University does not accept responsibility for any changes made after > it was sent. Nothing in this email or its attachments constitutes an order > for goods or services unless accompanied by an official order form.
