MongoDB Authentication¶
The MongoDB connector signs in with a User and a Password, checked against the database named in Auth Source. MongoDB's own challenge-response sign-in (SCRAM) is used, which is what MongoDB Atlas and most self-hosted deployments expect for database users.
Both credentials are optional. Leave User and Password empty only for a server that accepts connections without access control, such as a local test instance. Fill in both, or neither: a password without a user, or a user without a password, is refused before Qualytics tries to connect.
The user and the Auth Source¶
User is a MongoDB database user, not a person's Qualytics account and not an Atlas account login. On Atlas, create it under Database Access in the Atlas project.
Auth Source is the database where that user is defined. It is not the database you want to monitor, which you pick separately under Location. Most deployments define their users in admin, which is the default and what Atlas uses for every database user. Change it only when your user was created inside another database, for example a user created with use sales followed by db.createUser(...), whose Auth Source is sales.
A wrong Auth Source looks exactly like a wrong password: MongoDB refuses the sign-in without saying which part was wrong. Check it first when credentials you know are correct are refused.
What each field does¶
| Field | Required | What it is for |
|---|---|---|
| User | The MongoDB database user Qualytics signs in as. Required when Password is filled in. | |
| Password | That user's password. Required when User is filled in. Stored encrypted and never displayed back. | |
| Auth Source | The database the user is defined in. Defaults to admin. |
The connection's other settings, Host, Port, DNS Seed List (SRV), and SSL Connection, decide where Qualytics connects and whether the connection is encrypted. They are described in Add with a New Connection.
Credentials never go in the Host field
The Host field takes host names and ports only. A value containing @, /, ?, or a space is refused, so a user:password@host address cannot be pasted there. Enter the credentials in User and Password, where the password is stored encrypted.
Encryption in transit¶
Turn on SSL Connection to encrypt the connection with TLS. When DNS Seed List (SRV) is set to Yes (mongodb+srv, e.g. Atlas), TLS is always on, whatever SSL Connection says, which is what Atlas requires.
The form has no field for a custom certificate authority or a client certificate. The server's certificate must be one your Qualytics deployment already trusts, as is the case for Atlas.
How the credentials are stored¶
The password is stored encrypted and never displayed back to you. Once saved, the field shows that a value is stored rather than the value itself.
- To change the password, enter the new one and save.
- To keep the stored password while editing anything else on the connection, leave the field empty and save.
The user, the Auth Source, and the host settings are not secrets and are shown as saved.
Edits apply to every datastore on the connection
Credentials belong to the connection, not to a single datastore. Changing them through Manage Connections changes them for every datastore that reuses that connection.
See Also¶
-
Examples
Worked scenarios: a MongoDB Atlas cluster, a self-hosted replica set, collections whose documents vary, and several databases at once.
-
Best Practices
Recommendations for planning the connection, getting stable fields from the sample, and keeping operations fast.
-
Permissions
The access your MongoDB deployment must grant, plus the Qualytics user role and team permission needed to manage the datastore.
Credentials from a secrets manager
Any field on this page can take its value from HashiCorp Vault or another secrets manager instead of being typed in: enable Secrets Management on the connection and write ${key} in the field. See the HashiCorp Vault pages for setup and troubleshooting.