You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 22, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 22, 2020. It is now read-only.
Using a shared MongoClient or MongoDatabase instance聽#43
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.
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
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?
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.
Activity
[-]Shared MongoClient[/-][+]Using a shared MongoClient or MongoDatabase instance[/+]RobThree commentedon Oct 31, 2016
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.
Out of curiosity: why is that bad?
ducas commentedon Oct 31, 2016
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/
What part are you referring to? Initialising a db yourself or basing the repositories off a context?
RobThree commentedon Oct 31, 2016
When people can get to your
app.config(or whatever) and change your connectionstring (especially in production)sslVerifyCertificate=falseis 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?Both. But I do see some value in it.
ducas commentedon Oct 31, 2016
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 commentedon Oct 31, 2016
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.