вы много спорите о том, что в документации написано

вы сначала сделайте

не работает так

не работает как именно? что получилось?

но вообще я не понимаю что мешает выключить аутентификацию и удалить local без этих плясок

не работает как именно? что получилось?

> db.getUsers() [ { "_id" : "admin.root", "userId" : UUID("4f1015ba-853e-49c8-8618-d7443b585332"), "user" : "root", "db" : "admin", "roles" : [ { "role" : "root", "db" : "admin" } ] }, ... > db.grantRolesToUser("root", ["custom"]) > db.getUsers() [ { "_id" : "admin.root", "userId" : UUID("4f1015ba-853e-49c8-8618-d7443b585332"), "user" : "root", "db" : "admin", "roles" : [ { "role" : "custom", "db" : "admin" <===== }, { "role" : "root", "db" : "admin" } ] },

получилось как я и говорил, как в доках и написано, подставится admin

и теперь что у вас происходит при use local; db.dropDatabase()?

и теперь что у вас происходит при use local; db.dropDatabase()?

🤔🤷 Дропнулось. > use local switched to db local > db.dropDatabase() { "dropped" : "local", "ok" : 1 } Спасибо большое 🙏🙏🙏

и теперь вы узнали что в монге scope != source

и теперь что у вас происходит при use local; db.dropDatabase()?

Но ты все равно не прав насчет ролей и юзеров в базах. Их можно там создавать и это работает. Могу доказать

source это где храниться информация о привилегия

scope это к чему она применяется

admin это хранилище привелегий по умолчанию. эти привилегии распространяются на ЛЮБОЙ скоуп

да, вы можете выбрать ДРУГОЕ хранилище привелегий. Для того чтоб его использовать вам нужно будет явно в клиенте указать authDB

admin это хранилище привелегий по умолчанию. эти привилегии распространяются на ЛЮБОЙ скоуп

Но если создать пользователя например в базе test. Он сможет туда заходить и при этом его не будет в базе admin.

это монго-норкомания

не знаю зачем они это сделали, но это локализация хранилища

наверное чтоб было удобно разделять привилегии по базам

но из-за этого с терминологией получается каша

вы упорно пытались использовать хранилище привилегий local, но у вас туда нет по-умолчанию доступа

и он и не нужен

так как root может давать права куда угодно и кому угодно, нужно просто создать роль в admin, которая добавит ему привилегий к local

вы упорно пытались использовать хранилище привилегий local, но у вас туда нет по-умолчанию доступа

ну я же начал делать не от хорошей жизни. А от конкретной ошибки, когда пытался дать права на эту базу

вы это начали делать, считая что создание пользователей в другой базе имеет какое-то значение, но это не так

значение имеет скоуп привилегий

а не хранилище

хранилище это как passwd файл

вы это начали делать, считая что создание пользователей в другой базе имеет какое-то значение, но это не так

нет, я приводил оба варианта. Для наглядности А то что пользователь с ролью {"role" : "custom","db" : "admin"}. Может что-то делать в другой базе, странно

db здесь не скопу роли

А хранилище

Откуда её взять

db здесь не скопу роли

Хранилище же выбирается, когда ты выбираешь конкретную базу, в которой создает пользователя или роли. У роли тоже стоит db:"admin" > db.getRole('custom') { "role" : "custom", "db" : "admin", "isBuiltin" : false, "roles" : [ ], "inheritedRoles" : [ ] } Ну это видимо тоже хранилище

Да. Скоуп заедается через resource

Тогда не очень понятно. Как правильно дать доступ пользователю в другую базу, но при этом хранить его в admin. Я раньше делал так: user admin db.createUser({ user: "test", pwd: "password", roles: [{role: "readWrite", db: "test"}]}) И пользователь хранится в admin, при этом у него стоит db:"test". И это как-то противоречит твоему утверждению, что когда я так пытался делать для local, то я пытался сделать это в хранилище local

В монге полный бардак с этим. Даже после десяти лет с монгой я постоянно путаюсь что и где

Ещё хуже в случае с шардом

Потому что там будут cluster wide и shard local ветки привилегий

Ещё хуже в случае с шардом

ну если шарды, то по идее все доступы хранятся в config replocaset, если заходить через mongos, а если напрямую, то в самом шарде

Наоборот.

shard local это с реплики, а cluster wide это с конфига

И это два разных набора привилегий

Например для обслуживания шардов придётся руками ходить и везде обновлять пользователей и роли

Если к этому ещё аутентификацию по сертификатам добавить, будет бинго и полное ведро боли

db здесь не скопу роли

Ну должна быть же какая-то логика. Вот почему: Хранилище admin (а не test) user admin db.createUser({ user: "test", pwd: "password", roles: [{role: "readWrite", db: "test"}]}) А здесь хранилище local? user admin db.createUser({ user: "test", pwd: "password", roles: [{role: "readWrite", db: "local"}]}) ААА, хранилище для ролей это. Теперь понял

так как readWrite встроена везде (кроме local) первый случай работает корректно.

Да, это хранилище информации о привилегиях

The following roles are available on the admin database and provide privileges which apply to all databases except local and config:

^

А, тьфу. Это не про это

Да, это хранилище информации о привилегиях

То есть тогда правильно делать не так. А создать свою роль с readWrite на базу "test", и уже делать так: user admin db.createUser({ user: "test", pwd: "password", roles: [{role: "customRoleReadWriteForTest", db: "admin"}]}) И только в этом случае, юзер test будет в admin, и роль тоже в admin, но при этом он будет иметь доступ только в test

Да, именно так

Да, именно так

Все спасибо большое добрый человек! Теперь я вроде как понял эту жесть с правами

Но правда так делать неудобно получается, свои роли фигачить для юзера. Проще тогда их хранить в базах вместе с ролями. Просто поминть, что с local так не выйдет, так как по умолчанию нету прав создавать там роли и юзеров

Жесть какая))

без необходимости хранить за пределами admin не стоит

так как при подключении вам нужно будет явно настраивать authenticationDatabase

и указывать ту, откуда вы хотите брать список пользователей и ролей

так как при подключении вам нужно будет явно настраивать authenticationDatabase

странно, я как раз таки наоборот делаю, именно потому что authenticationDatabase по умолчанию используется та база, к которой коннект присходит. По крайней мере в mongo модуле для nodejs

вопрос: может ли монга сторить бинарник ~10кб в документе без сериализации в base64?

вопрос: может ли монга сторить бинарник ~10кб в документе без сериализации в base64?

да. в Binary bson type

да. в Binary bson type

а почему в клиентской проге я вижу, что он в base64? или это для удобства?

Если там Binary(…, <base64>), то да, для удобства

тогда понятно, спасибо

странно, я как раз таки наоборот делаю, именно потому что authenticationDatabase по умолчанию используется та база, к которой коннект присходит. По крайней мере в mongo модуле для nodejs

а это ещё один уровень веселья, это зависит от того как вы настраиваете подключение

потому что uri string будет работать вот так

Specify the database name associated with the user’s credentials. If authSource is unspecified, authSource defaults to the defaultauthdb specified in the connection string. If defaultauthdb is unspecified, then authSource defaults to admin.

TL;DR: при подключении не стоит указывать базы данных или authDB

Specify the database name associated with the user’s credentials. If authSource is unspecified, authSource defaults to the defaultauthdb specified in the connection string. If defaultauthdb is unspecified, then authSource defaults to admin.

ну да, видимо все наши прогеры указывают. ну и пусть. Зато в одном месте хранится и роль и юзер.

Всем привет! В какой ситуации монгод может выбирать разные индексы на один и тот же запрос? Есть коллекция в боевой базе, делаю с неё дамп, ресторю на локальный монгод в докере вместе с индексами (версия сервера та же, отличаются тем что локально один сервер, а в боевой есть репликация). Делаю два одинаковых запроса в боевую и локальную, по логам видно что используются разные IXSCAN. В обоих случаях составные индексы. Просто в одном случае он обходит n документов, в другом 10*n

Всем привет! В какой ситуации монгод может выбирать разные индексы на один и тот же запрос? Есть коллекция в боевой базе, делаю с неё дамп, ресторю на локальный монгод в докере вместе с индексами (версия сервера та же, отличаются тем что локально один сервер, а в боевой есть репликация). Делаю два одинаковых запроса в боевую и локальную, по логам видно что используются разные IXSCAN. В обоих случаях составные индексы. Просто в одном случае он обходит n документов, в другом 10*n

В момент когда в первый раз выполняется запрос по шейпу, который не находится в кеше планов, монга пытается предсказать сколько времени и ресурсов займёт по каждому из подходящих под этот шейп планов, выполняя тестовую выборку. Какой план будет дешевле, тот и победит и попадёт в кеш. Почему выйграл один план, но проиграл другой сказать сложно. Причин много, начиная от нагрузки в момент выполнения тестовых выборок, заканчивая количеством попавших в неё документов. Если вы хотите чтоб монга выбирала конкретный индекс, то используйте hint

спасибо) а где об этом почитать подробнее?

в доке не помню таких подробностей

https://docs.mongodb.com/manual/reference/operator/meta/hint/ https://docs.mongodb.com/manual/core/query-plans/

The evaluation of the most efficient query plan is based on the number of “work units” (works) performed by the query execution plan when the query planner evaluates candidate plans.

спасибо!

Привет! Нужен wildcard-индекс такого рода: db.mycoll.createIndex( { "manual_responsibilities.$**.responsibility_class_id": 1 } );. Думаю из строки понятно, что я пытаюсь сделать. Но монга не дает такое провернуть. Есть ли способ это обойти?

Привет! Нужен wildcard-индекс такого рода: db.mycoll.createIndex( { "manual_responsibilities.$**.responsibility_class_id": 1 } );. Думаю из строки понятно, что я пытаюсь сделать. Но монга не дает такое провернуть. Есть ли способ это обойти?

Каждый раз создавать новый индекс при появлении нового значения, это можно автоматизировать, но это такое себе решение, проще сделать такую схему данных, где не возникнет такой проблемы

Каждый раз создавать новый индекс при появлении нового значения, это можно автоматизировать, но это такое себе решение, проще сделать такую схему данных, где не возникнет такой проблемы

спасибо. То есть с помощью wildcard такое нельзя сделать вообще, получается?

спасибо. То есть с помощью wildcard такое нельзя сделать вообще, получается?

Вообще в доке написано, что: «The wildcard index can support arbitrary single-field queries on product_attributes or its embedded fields»

И судя по примеру если вы создаёте индекс manual_responsibility.$**, то можете рассчитывать на индекс по всем вложенным полям

И судя по примеру если вы создаёте индекс manual_responsibility.$**, то можете рассчитывать на индекс по всем вложенным полям

спасибо!