Using a shared MongoClient or MongoDatabase instance

[ducas]

I'm using a MongoDB instance behind self-signed SSL, which means that to use this project I need to include sslVerifyCertificate=false on my connection string... that's bad. 😢

Do you think it would be a good idea to be able to initialise a MongoRepository by passing it a MongoClient. e.g.

var settings = new MongoClientSettings{ /*...*/ }
var client = new MongoClient(settings);
var db = client.GetServer().GetDatabase("mydb");
var repository = new MongoRepository(db, "mycollection");

Also it could be good to have a factory or context that provides the repositories -

var context = new MongoContext(db);
var repository = context.Repository<MyType>("mycollection");

This way you could pass an initialised context around and easily create repositories.

[RobThree]

I think this exposes too much mongo-specific stuff. On the other hand I think it could be handy to pass in a collection to the constructor. Let me sleep on it for a while.

which means that to use this project I need to include sslVerifyCertificate=false on my connection string... that's bad

Out of curiosity: why is that bad?

[ducas]

sslVerifyCertificate=false is leaving yourself vulnerable to man in the middle attacks... not something you want in production - http://mongodb.github.io/mongo-csharp-driver/2.2/reference/driver/ssl/

I think this exposes too much mongo-specific stuff

What part are you referring to? Initialising a db yourself or basing the repositories off a context?

[RobThree]

When people can get to your app.config (or whatever) and change your connectionstring (especially in production) sslVerifyCertificate=false is the least of your problems I think? Or am I missing something?

Also I don't see how moving that setting to code solves the problem then? You'll have to specify somewhere that you do/don't want to use sslVerifyCertificate, right?

What part are you referring to? Initialising a db yourself or basing the repositories off a context?

Both. But I do see some value in it.

[ducas]

Instead of sslVerifyCertificate=false, you can verify the public key of the endpoint you are connecting to. This will ensure you are connecting to the database server you intend to connect to rather than another party impersonating that service. This is especially crucial if using a server hosted by a 3rd party provider that may be in a different datacenter. That link I provided gives the code for specifying the certificate of the server you expect to be connecting to in order to verify the certificate is correct.

Ok - feel free to sleep on it. 😄

[RobThree]

Instead of sslVerifyCertificate=false, you can verify the public key of the endpoint you are connecting to.

Ah, I see. The point is to be able to specify the public key / affect the SSL handshake. That makes more sense.

I think adding an constructor overload specifying a collection is no problem. Will try to add it soon.