Skip to content

MONGOSH-523 - AutoEncryption only run on enterprise #545

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 14, 2021
Merged

Conversation

aherlihy
Copy link
Contributor

The best solution I could find was connecting twice, once with the autoencryption options entirely removed. This connection runs buildInfo, and if it's not enterprise, then it will close the connection and error. If it is enterprise, then it will close the connection and reconnect with the autoencryption options included.

TODO: the message that is thrown should be written & reviewed by the legal team per @mmarcon

!(buildInfo.modules && buildInfo.modules.indexOf('enterprise') !== -1)
) {
await client.close();
throw new MongoshRuntimeError('Cannot turn on automatic encryption for connections to non-enterprise hosts');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is TBD

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about the regex on gitVersion. At least for our Atlas cluster, this is the first part of the buildInfo output:

{
  version: '4.2.11',
  gitVersion: 'ea38428f0c6742c7c2c7f677e73d79e17a2aab96',
  modules: [ 'enterprise' ],
 ...
}

Why were you thinking of checking gitVersion in addition to modules?

Another minor thing: buildInfo.modules.indexOf('enterprise') !== -1 can be rewritten as buildInfo.modules.includes('enterprise'). I think Typescript also supports optional chaining so you can probably write the second condition as

buildInfo.modules?.includes('enterprise')

As for the copy of the error message, I'd go for something like:
Automatic encryption is only available with Atlas and MongoDB Enterprise. I'll get that reviewed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other minor thing: not sure if we do it for the other errors, and not sure if this is special, but would it make sense to put this in the i18n package and read it from there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took it directly from the mongodb-build-info package, which is what we're using in the rest of the shell to determine if it's an enterprise cluster. I also found only the git hash without 'enterprise' when I tested locally, but I thought it could possibly be from older versions before they had modules in buildInfo. I have a very vague memory of Irina mentioning the git hash with enterprise, but I can't find that conversation. We may want to improve the check there as well (placeholder jira ticket).

Per the i18n error message, we don't yet use i18n for error messages everywhere but that's certainly a future feature we should track in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From this stack overflow it seems like it may happen sometimes that the gitversion has enterprise: https://stackoverflow.com/questions/33160352/how-to-check-if-mongodb-enterprise-is-in-use but it may be an older version than we support

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, ok, it's cool then. Thank you for clarifying.

* @param clientOptions {MongoClientOptions}
* @param mClient {MongoClient}
*/
export async function connectMongoClient(uri: string, clientOptions: MongoClientOptions, mClient = MongoClient): Promise<MongoClient | void> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When would this not return a Promise<MongoClient>?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it would! Good catch - I previously had it looking like

if (x) {
    return y;
} 
throw z

which I just learned you can't have the function signature return just the type of y. Then I refactored to avoid that issue, but then forgot to update the signature 🤦

@aherlihy aherlihy merged commit 583947a into master Jan 14, 2021
@aherlihy aherlihy deleted the 523-dev branch January 14, 2021 10:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants