I read through several docs on mongodb but I'm so confused that I'm posting this question.
Is there a way to set a password for a mongodb database? That ways when I try to open the database via console or connect using mongoose/node.js I will need a password.
Thank you.
There is the "auth" parameter to start mongod with required authentication.
Therefor you have to create an admin user (a user which has admin privilegs like - creating other users and so on) and then you can create a user for read, readwrite or write rights for specific databases.
http://docs.mongodb.org/manual/reference/method/db.createUser/#create-administrative-user-with-roles
http://docs.mongodb.org/manual/reference/method/db.createUser/#create-user-with-roles
Important is, that you start your mongo db with the auth parameter after creating these users.
mongod --auth
Related
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!
I'm integrating prisma with nestjs
I want to know all the basic database user permissions required for prisma commands like migrate i.e. pull/push/deploy/dev etc.
We do not wish to give complete admin access and only wish to assign a few roles/permissions to user to perform basic CRUD tasks.
Here are the permissions which is required for prisma migrate
PostgreSQL - The user must be a super user or have CREATEDB privilege.
MySQL - Database user must have CREATE, ALTER, DROP, REFERENCES ON . privileges.
SQL Server - The user must be a site admin or have the SERVER securable.
You can know more about it here: Reference
I followed this guide https://www.mssqltips.com/sqlservertip/5242/adding-users-to-azure-sql-databases/ to create a new user for my back-end API with restricted permissions for basic security reasons but can't make the back-end connect to the server. Every time it tries to connect I'm getting
System.Data.SqlClient.SqlException: 'Login failed for user 'xxxx'.'
I'm able to log-in this new user via SSMS by setting the target database in the login window options.
The back-end can connect just fine with the default connection string supplied by the Azure Portal, witch uses the server admin login. Changing the username and password for the new user, keeping the Initial Catalog to my desired database does not work.
I would assume the back-end would be able to access it since the Initial Catalog property of the connection string is set to the database the contained user was created on. But nothing is working.
This is my connection string used on my back-end:
Server=tcp:xxx.database.windows.net,1433;Initial Catalog=dbName;Persist
Security Info=False;User
ID=newUser;Password=newUserPw;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection
Timeout=30;
I tried many guides but none worked before I found this one that seems to be very knowledgeable about creating Azure SQL users, but even so no luck so far.
This are the commands I used to create the user on the DB I need it to connect(ofc with my own values):
-- select your db in dropdown and create a contained user
CREATE USER [test]
WITH PASSWORD = 'SuperSecret!',
DEFAULT_SCHEMA = dbo;
-- add user to role(s) in db
ALTER ROLE db_datareader ADD MEMBER [test];
ALTER ROLE db_datawriter ADD MEMBER [test];
Anyone knows whats going on? I don't want to have to use my admin login on my back-end.
Turns out the straight answer is to set
Persist Security Info=True;
in the connection string.
When username and password are included in connection string, security-sensitive information such as the password, is not returned as part of the connection if the connection is open or has ever been in an open state unless you set Persist Security info to true.
Reference: Persist Security Info , sqlconnectionstringbuilder
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"
On many varieties of Linux PostgreSQL runs under a separate user account, so you have to do:
sudo su - postgres
to get any work done. That's all well and good if you just want to type SQL in manually, but what if you have a migration written in a programming language (in my case, Node/Knex)?
Is the common practice to somehow make the code aware of the user situation (ie. write something equivalent to sudo su - postgres in to my code)?
Or, is it to run all of my code as the DB user (even though that would mean giving my DB user permissions on my non-DB user's home folder)?
Or, is it to make my normal user have Postgres access (in which case why does Linux even bother setting Postgres up on a separate user)?
Or, is there some other approach I'm missing?
P.S. I realize this is somewhat a systems administration question, but I posted here rather than super user because it's specifically about running programmer-written code (which just happens to alter a database).
You are conflating three separate user accounts.
First there is the OS account under which the postgresql daemon runs. As you say in most Linux distros this would be a separate user used only for this purpose, often named postgres. This is to prevent other users on the system from accessing the postgresql data files and other resources, and also to limit the damage that could be done by someone who hacked their way into the database.
Then there is the user account which the client program, such as psql or your migration tool might run under.
Finally there is the postgresql user account. Postgresql has it's own user account system to manage the permissions of users within the databases that it administrates, unconnected to the OS user account system.
The one are of overlap between the OS accounts and the postgresql database accounts is that the psql command line tool will connect to the database using a user name the same as the OS user running the tool if you do not specify a user on the command line. For example, if I connect with this:
psql mydatabase
then it will attempt to connect with the user harmic, my Linux user account, but if I use this:
psql -U postgres mydatabase
then it will connect with the user postgres, which is the default administrator account.
Another related aspect is the authentication method. Most likely, if you try the above command on your machine, you would get an error. This is due to the allowed authentication methods, which are configured in the file pg_hba.conf. This file configures allowed authentication methods that specific users can use when connecting to specific databases from specific hosts. The postgres user is normally only allowed to connect from within the same host, using ident as the authentication method, which means identify the user based on the OS user running the command.
This explains why you have been using sudo su - postgres to switch to the postgres user: most likely in your current configuration that is the only way to access this account.
OK, this probably all sounds rather complex. To simplify things, here are my recommendations for best practices in this area:
Do not mess with the OS account used to run the database backend. It is not needed and would weaken security.
Create a separate database account for administrating the application's database(s). Use this account rather than the postgres account for migration scripts and the like. The reason for this is that the postgres account has full permissions over all databases on the server, while you can grant your admin user only the permissions it needs, and only to the database(s) the application controls (not any other databases that might be there). See: CREATE USER SQL command.
Update the pg_hba.conf file to specify the authentication mode that will be used to authenticate this user. See Client Authentication in the manual. md5 with a suitably strong password might be a good choice.
Update your migration tool to use this new user. The user (and password if using passwords) would be supplied via the connection string or connection parameters supplied when connecting to the database. Likewise when connecting with psql specify the user name with the -U option.
Note that there is no need to use sudo su - or even to have an OS account with the same name as the admin user.