Alrighty, so I have a MongoDB Atlas database set up, containing several objects. My current API has several get, post, put and delete end points which are working correctly. However, I am in the process of setting up user accounts and I am a little confused.
My project is built with React on the front end and my server is built with Node, express and mongoose. My goal is that of your typical web application and is as follows:
Go to main web app URL
Home page is a login or "create an account" screen.
Once logged in (or an account is created and you sign into it) you will then have access to get, post, put and potentially delete (if an admin) objects in my DB.
I have built a very basic sign-in, sign-out and "register an account" server which is working however, I am confused as to how to properly go about integrating this with the rest of my API. I currently have the server connecting to my Atlas DB using what is provided in the "connect" menu in the Atlas dashboard (without the < >)
mongodb+srv://<username>:<password>#<cluster-name>.ntwp5.mongodb.net/<collection-name>
Obviously, the username and password (which I can set in my Atlas dashboard) needs to be passed into the "username" and "password" fields in-order to connect to it. I was planning to use the same cluster and have a separate collection for users and my data.
What's confusing me is that in-order to connect to the MongoDB server above and gain access to the two databases, I need to pass in some username/password. However, in order to create an account (ie, creating a new username and password), I would already be utilizing a username and password to connect to the server.
So say I have a group of people in the same company using this application. Would I essentially have a single administrative username/password used by everyone to connect to the server URL? From there, users would be able to access the "users" collection and create an account. Do I then setup my existing API routes (which point to my collection of data) to check that the "signed-in" user exists before returning a successful request and access to that collection?
Or perhaps, the proper way is to use two completely separate databases; one for users and one for my data?
Sorry, I am new to working with Databases and I think the above makes sense to me but I want to verify if that is the correct way to go about handling this. Thanks!
Related
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 have an express.js application where clients authenticate using a local strategy (passport.js). After that I want them to be able to create empty documents with titles of their wish (I create a new mongoose 'Task' document and set its doclink (Task.doclink) to be the newly created document's public link (https://docs.google.com/document/d/...document_id.../edit)).
I want this new document to be created in a particular google account that I have access to (the clients don't have direct access to it but they can create documents inside it and write to it)
Any suggestions of how I should go about authorization of google API? As per my current research, this seems impossible.
What I would recommend you to use is a service account as the docs say:
A service account is an identity that an instance or an application
can use to run API requests on your behalf.
What it means is that you will be able to have a "bot user" in your express app, which could be the interface between your users and your document.
Docs
You can check more about it in these links:
Creating and managing service accounts.
Authenticating users with Node.js.
I have made a Java ExtLib XPage custom REST service (CustomServiceBean) database basing on this solution: https://setza-projects.atlassian.net/wiki/spaces/RS/pages/363593730/IBM+Domino
I modified it though to use NotesCalendar class to create, update and delete events & resource reservations (so everything in fact is processed by the calendar, I'm only using raw documents for reading $Rooms in names.nsf and $Reservations in the reservations database). Everything works fine so far, it uses current session to open the calendar. I have some concerns regarding the permissions though.
What I want (and need):
Ability to create calendar events & reservations as SPECIFIC users, I don't want just one "main" user that will create everything. I want each IBM Lotus user to be able to login with their credentials and create or update their calendar events.
This database with XPage will be deployed on our client's servers, so I don't want to require some special configuring for each user in order to be able to access my REST service.
I set up a new local installation of Lotus Server and created a new application using my XPage database as template, and I couldn't access the API neither with admin account or other accounts:
HTTP JVM: CLFAD0229E: Security exception occurred servicing request for: /db.nsf/services.xsp/api - HTTP Code: 403. For more detailed information, please consult error-log-0.xml
As soon as I added my admin account to Server configuration -> Security -> Sign or run unrestricted methods and operations, it started working again. Not only for the admin account, but also for other accounts that were just created with an internet password and weren't assigned any specific roles or permissions. I didn't even sign the database.
So my question is, is this enough in order to get it working on client's production server? It kind of makes no sense to me, but it worked on my local server so I'm not sure, I'm new to IBM Lotus and I'm just doing an integration REST service.
If not, how could I do it, so I wouldn't really need to put the end client (Lotus server owner) into the hassle of configuring each user, while still being able to access the API as any Lotus user (providing the username and password)? I can either log-in as each indepentend user, or perform some impersonation with a "main" privileged account (create entries in someone else's calendar as him), although I think there is no way to do it in Java, because .getCalendar is a method of the Session class, I tried using createSession(), but I wasn't able to.
Every notes application needs to be signed by an administrator with an ID known to the customers environment. The Id which is used to sign the db must have the appropriate rights, through the security tab in the server document. If the app is not signed properly, the app won't run. Once the app is signed, it runs in the authorized users session with the users rights.
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.
In response to a question I asked about a week ago I changed our database engine to only accept Windows Authentication instead of SQL Authentication. Because our code runs in a different user context then that of the database connection we need to specify the username and password information in order for us to connect to the database. How do we do this using a ConnectionString? Remember, we are not using SQL Authentication anymore.
Thanks,
On your SQL Server instance, you need to add the domain group under the Security node (the one in the main server group, not in the individual databases). Under that node, the end result would be an item that resembles
<Your Domain>\Domain Users
Then in your application (Windows or Web) connection strings you want to set integrated security to be TRUE, and elsewhere, you need to set Impersonation to also be True. I am being vague here because the methods vary by application type.
Hopefully that sets you on the correct path.
Since you are using only Windows authentication, you can't in the connection string. The calling process will need to impersonate a windows principle (user) with the relevant access permissions.