Nosql уязвимость mongoDb, как не допустить?

Question

[IDONTSUDO]

Я нашел у mongoDB. Функционал для генерации object Id документа. И по скольку мне нужно делать микросервисы. Я хочу его использовать для генераций, ссесий. Я не могу сделать эту генерацию через какую либо ODM. Если я сделаю ее через нативный драйвер, приведет ли то к NoSQL уязвимости? И если это приведет к уязвимости, то как защитить базу?

Чтобы сгенерировать новый ObjectId, используя ObjectId()уникальную шестнадцатеричную строку:

x = ObjectId ()

ObjectId ( "507f1f77bcf86cd799439011" )

Comments

[pcdesign]

Я хочу его использовать для генераций

Это из области: у меня есть нож, но я хочу начать им забивать гвозди. Не порежусь ли я при этом?

Почему бы не использовать готовые решения:
https://stackoverflow.com/questions/23169509/mongo...

[IDONTSUDO]

pcdesign, я использую JWT и микросервисы. Не думаю что мне это подойдет, но спасибо.

Answer 1

[Robur]

Если я правильно вас понял - то вы хотите использовать ObjectId для генерации ID сессии.
Первый вопрос - зачем?
Второй - чем не угодили любые другие способы генерации Id - тот же UID
Третий - зачем вам ID сессии вообще, если у вас JWT - который сам по себе и есть токен сесии? Кладите туда всю нужную инфу, подписывайте, проверяйте подпись при запросе и будет вам счастье.

Comments

[IDONTSUDO]

Это сложно понять возможно, но я постараюсь описать максимально понятно.

Потому что, вот смотрите есть условно 4 микросервиса. Каждый отвечает за разный функционал. По сути.

localhost:8080 авторизация личный профиль
localhost:8081 лайки
localhost:8082 друзья
localhost:8083 сообщения
localhost:8084 обслуживание пользовательской стены

Юзер регестрируется и авторизуются в 1 серверисе. Идет генерация, его колекции. И адрес его страницы становится localhost:8080/myprofile/qwe9102j0fjkfqweka0.

где

qwe9102j0fjkfqweka0 - является ID сессии юзера. По сути, когда мы обращаемся по этому пути. Показывается qwe9102j0fjkfqweka0 колекция в mongodb с этим object ID.

Когда мы начинаем думать над тем, как это будет устроено со стороны остальных 4 серверов. То при первом обращении, пользователя. Генерируется снова Object Id. И да JWT тут работает на отлично. Но юзер не доступен по адресу qwe9102j0fjkfqweka0. Так как адрес его колекции меняется. И если таких серверов еще 4 то получается данные лежат на 4 серверах, децентрализовано. И ни как не связаны. В этом моя проблема.

Можно придумать велосипед. Из не повторимого алгоритма, только это приводит к тому что приходится дублировать информацию. А я не хочу этого делать.

[Robur]

IDONTSUDO,
1) вы как раз какой-то велосипед и изобретаете.
2) то что вы называете сессией пользователя - это не сессия, это просто его данные.

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

Микросервисы значат что у вас авторизацией пользователя занимается один сервис - он же делает id, он же создает JWT токен. Данными занимаются другие сервисы - но только этими данными, id пользователя они никак не генерят, не делают под него новые коллекции и все такое.

Если пользователя надо как-то обработать в сервисе лайков - то сервис лайков идет в сервис авторизации/личного профиля и получает там инфу пользователя, в том числе его id. Он не должен придумывать для пользователя какой-то новый ID.

То при первом обращении, пользователя. Генерируется снова Object Id.

нет, при первом обращении пользователя остальные сервисы отправляют его на localhost:8080, который генерит JWT токен в котором лежит id= qwe9102j0fjkfqweka0, этот jwt приезжает обратно на другие сервисы, которые его просто используют.

И ни как не связаны. В этом моя проблема.

Ваша проблема что вы за одни и те же данные хотите сделать ответственными разные сервисы. Не надо так делать.
id для "сессии" пользователя должен создавать ТОЛЬКО сервис авторизации/профиля. Остальные его берут из JWT токена и используют.

Почитайте OAuth/OpenID - они как раз сделаны для подобных схем взаимодействия