MongoDBPurger and non existent collections with MongoDB authorization enabled

[redthor]

We are using the MongoDBPurger but we found that adding authorization: enabled to /etc/mongodb.conf causes it to fail, due to:

https://jira.mongodb.org/browse/PHPLIB-277

I thought another way to avoid ^^ is to ask the Purger to ignore embedded documents. They do not have a collection.

Therefore I have changed the MongoDBPurger code and added ! $metadata->isEmbeddedDocument here: https://github.com/doctrine/data-fixtures/blob/master/lib/Doctrine/Common/DataFixtures/Purger/MongoDBPurger.php#L69

            if ( ! $metadata->isMappedSuperclass && ! $metadata->isEmbeddedDocument) {
                $this->dm->getDocumentCollection($metadata->name)->drop();
            }

I wanted to prove it so I tried the test but I ran into https://github.com/doctrine/data-fixtures/issues/263

[redthor]

Of course, using the MongoDBPurger and having authorization: enabled may not be a use case you will want to support! I had to have it on in my dev env for testing. My workaround is to turn off security, restart mongodb, run the purger, and then turn security back on.

[Ocramius]

The purger is designed for test scenarios, so I'm not sure if this is a valid use-case scenario.

Is this an issue arising in your test setup, or otherwise where?

On 4 Aug 2017 05:25, "Douglas Reith" notifications@github.com wrote:

Of course, using the MongoDBPurger and having authorization: enabled may not be a use case you will want to support! I had to have it on in my dev env for testing. My workaround is to turn off security, restart mongodb, run the purger, and then turn security back on.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/doctrine/data-fixtures/issues/264#issuecomment-320146548, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakMudCvOtXsRSiBDVi-BKokOo9TbKks5sUo8SgaJpZM4OtOVV .

[redthor]

We're using the Purger as part of a clean down script for our development environment. So it's not being used in our tests as such.

To be fair it isn't doing much so we could just override or re-implement - happy for it to be closed.

[alcaeus]

TBH, even in test environments it might be feasible to run with authorization: enabled, so I'd consider this a valid issue. As for the check you mentioned above, it might be better to change it to if ($metadata->isDocument) for now since we're adding another document type without collection (query result documents) in MongoDB ODM 1.2, which would require the check to be extended once again. Documents have collections that can be dropped, everything else doesn't ;)

[jmikola]

I replied in PHPLIB-277, but I'm curious if the authenticated user actually possessed the dropCollection role at the database level or not. If so, that may be an oddity with MongoDB's drop command. A "not authorized" error when dropping a collection that the user would have permission to drop if it existed leaves the driver with no way to easily detect the "ns not found" case that we want to ignore.

I assume there's no good reason for the purger to drop embedded documents, so that may in itself be a bug.