I'm new to couchDB and still reading tutorials. My question is if it is the normal way to represent every user of my application as a new database user, as it seems to be explained that way everywhere I look?
Let's say I have an online game with many different players - would I create a new "database user" for every player who registers? Or would I make my own database "players" and create a sign-in logic in the app? Not being used to document-driven DB's it seems strange to me not to distinguish between db-users and users of my application...
You could do it either way. First about couchdb users
Users in couchdb are stored in a special _users database
Database permissions are handled by a special _security document. This is specific to every database.
In security documents you add users that you have already stored in the _users database previously.
So you can certainly create a database per user. Before doing that ask yourself if the data that you store in each database is truly independent. Because you can't run map reduce queries across databases. So if you are planning to do aggregation across data for different users then this approach will not work.
Couchdb can also help you with app level authentication. Since couchdb uses a cookie based authentication:
Store your "business logic users" in the special _users database.
Authenticate it with the _session endpoint.
Extract the cookie header and sent it with your application headers.
All the logic for authentication is implemented for you by couchdb. All you have got to do is manipulate headers. Send the cookie from your application and when authenticating with couchdb send it with couchdb's headers.
If you prefer to write entire session management in your application that is fine too. In this case simply store the users in your database and verify that they exist before authenticating them. Like you would do with another database.
The benefit of using couchdb is that it is secure by default --using pbkdf2 encryption scheme to encrypt passwords.
If you instead want to manage all docs using a single database, but still implementing read/write ACLs, you can check the Chatty Couchapp Tutorial app from Smileupps App Store
It's a pure couchapp, relying on CouchDB only as its backend. The tutorial is still work in progress but the couchapp is fully working and you can download its source code.
It implements role/user based read/write ACLs using a single CouchDB database. This way you don't have to setup N replications where N depends on the number of your users. You only have one database containing all your data, easy to be queried on the fly(with temporary views) and for maintenance operations. Of course you can decide to increase the number of database, depending on type of your data and use cases.
A single couchapp contains all the necessary code for frontend, admin dashboard and server side API implementing business rules
The user, depending on his roles have different access to different sections. i.e. he can access the frontend website, but not the admin dashboard.
You can install the free trial, then download the source code with Smileupps deployment tools, change it, upload it back and check your changes.
Related
I only wish to employ Auth0 as my application's API provider but otherwise
would prefer to maintain any and all data about my users within my application's own database, thus, as one might well surmise, my application's database contains a users table along with several related tables. So, once a user signs up for my app, I'd need to create records for that user within the database. Then, once the user logs in via Auth0, I'd like to retrieve that user's data via information contained within the access token. (The field that presents itself as most useful for this purpose is "azp," or "authorized party.")
I'm thinking that, once the user signs up, as part of the effort to create the relevant records within the database, I'd save the "authorized party" value to a field on the users table. (Which field I cannot say, but, for now, this seems as sound a plan as any.) Then, when the user logs in via the Auth0 hosted API, I would retrieve their record from the database via the "authorized party" value.
Does this sound like a reasonable/sound plan? This is my first time building a full-on application from scratch, and, well, this particular detail has me scratching my head.
I am developing a frontend with ANGULAR and backend with Node and Express. Is a simple backend for internal use in my company with a small quantity of users: 15-20. The backend connects to Mongodb. The mongo server is started with authentication and I can create users with built-in roles in mongo: read, write, etc.
But all the examples I found in tutorials usually creates a collection of users instead of using the mongodb built-in users.
As far I know, if use built-in mongo users I need to start a new connection for each user because the user and password is part of the Connection String URI
I have some doubts:
Is it a bad idea to use built-in users?
If I use built-in users. How to manage the logout of the user? I don't find examples.
"Users" in this context is usually connections to the database.
Lets say you have a database with data serving several applications. One which only has access to read the data, and another to write and update. You can make sure the read only app, wont write with 2 users of the database. Typically, you'll also have an admin user that has global all access for administrators.
When your coworkers wish to update some data through the second application. The application will authenticate to the database and write on their behalf. Whether or not someone has access to use the application to update data is not something the database should decide.
I hope this helps to understand the context of "user"
I am working to create POS(Point of sale) application using couchdb with angular. Since i am beginner to NoSQL world. Need guidance to how to design the system.
It should be cloud based application, where login user can create companies and each company has n locations.
In relational database sense, my database design look like this.
While logging to my application, username & password validated against license db. If they are valid application will connect their own company db.
Whenever user create new company, new database will be created, all their locations, invoices, payments are in their own db.
License db responsible for user accounts, payments and their plan and level of security(which screen they can access/edit).
The application has offline support using PouchDB. where relevant location details are downloaded to user browser, and they synced back to server DB.
Questions:
Is it ok to create database for each company.
If user wants offline operation, they can sync own location data only(filtered replication), if they want to access other location data, application should connect cloud DB.Is it possible?
I want the same code to query/insert data in couchdb & PouchDB. Is it possible?
Is couchdb map-reduce/mango query support complex reports
Is Angular+Couchdb is enough, or do I need any server side framework.I don't any third-party authentication right now.
How the above relational database design should be implemented in couch db
what are the other things i should think about this software design
Yes. One common design for CouchDB is to have a database per user. One per company is totally reasonable.
CouchDB supports filtered replication. You could setup a filtered replication for user's documents on a local database instance (PouchDB or CouchDB)
PouchDB allows you to connect to CouchDB. Basically, you could have a PouchDB library that does all your business operations. You would only need to change the database adapter for the cloud or client database.
Map/Reduce is pretty straight forward. It allows you to index documents and query them by their keys. You can easily change the values in your indexes and also use reduce functions. Mango queries are more flexible. A bit similar to MongoDB.
You might eventually needs an application layer but that's possible to use only CouchDB.
I am building a tiny service with API in front of a CouchDB database.
For the API, I needed to build a script verifying and pre-filtering user requests to achieve doc-specific read permissions.
I am still using CouchDB's user management for user accounts, but every request goes through an nodejs/express server that then builds the requests to the DBs.
Now I am wondering whether I should
use the design_docs and validate_doc_update functions of CouchDBs own query server to filter document updates
or
I can manage document updates within my express-server by checking the _security doc from there.
I suppose because the query-server talks directly to CouchDB through stdio validate_doc_update has performance advantages? How great are they over making a get-request to a CouchDB _security doc and the following with an insert request to CouchDB?
Are there any other advantages of one approach over the other?
I am trying to use the new authentication system and I cannot find any decent articles/documentation to get what i want. Plenty of stuff out there explaining how the authentication process works out of the box but realistically you will need more.
First of all how do you control which database you store user information? I have read in many place that you can add a connection string. Ok great, but how do you get that connection string to be used by the authentication system?
And how would this work in a web farm, assuming user account information is split across databases with a little piece of logic which decides which database a user should login against?
I have used keystone extensively and it really isnt bad to implement. Its the authentication mechanism of Openstack. Check it out here http://docs.openstack.org/developer/keystone/
To answer your question users would first authenticate with it, receive a token, then they would present their token at any of your servers. If your data is split up, you can configure keystone to only allow access to certain areas of you backend via groups.
Changing the underlying database needs to steps. You have to add the connection string for the database you want to use for Identity. After this you have to change the base constructor call in your DB context to pass your new connection string to the base class (this is your missing step). An example for it is shown in this thread.
For your second question I don't have a good answer, because I haven't used Identity in a multiple DB servers scenario yet.