Привет ребят, нужна консультация. / python :: базы данных :: it :: разработка :: пидоры помогите (реактор помоги)

Привет ребят, нужна консультация. Попалась задача, дано:

1) Инстанс Databricks (AWS) в UK

2) Копроративная финтех софтина в US

Цель: tokenized JDBC коннекшен m2m, возможность забирать датасеты из датабрикса в UK и писать в локальную базу в штатах.

Проблемы:

- Софтина не поддерживает Databricks нативно, но поддеживает дженерик JDBC коннехуны.

- Токены выдает пропиретарный ID провайдер и они экспйрятся каждый час.

Возможное решение: Питон апп, который будет ходить к местному Principal и просить токен, после чего включать счетчик и обновлять его каждый час. Токен размещать в ENV VAR сервера с софтиной, в JDBC URL connection template соответственно подсовывать ENV VAR где хранится полученный токен.

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

Сразу хочу сказать, что это не совсем моя область знаний, поэтому и прошу советов.

Подробнее

пидоры помогите,реактор помоги,it,разработка,базы данных,python

Еще на тему

пидоры помогите(7570)

Развернуть

Отличный комментарий!

неч^равятся твшдшЩные словэ, магический чувак

Gaggablaghblagh13.10.202418:45ссылка

+17.7

Комментарии 3013.10.202418:34ссылка-14.2

Мне кажется, надо на реддите такое спрашивать

Mambateam13.10.202418:38ответить ссылка 2.5

У нас тут немало специалистов тоже, почему нет.

омич13.10.202418:39ответить ссылка ↑ -0.3

Также оговорюсь, что сфера сильно не моя, но уточню.

А разве коннект не закрывается при не правильном токене ?

A66aT13.10.202418:38ответить ссылка 2.8

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

омич13.10.202418:42ответить ссылка ↑ -0.6

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

Если так, то возникнет проблема, что
1. Тебе полюбому нужно где-то локально хранить актуальный токен со временем экспайра, иначе остальные коннекты после обновления не будут иметь к нему доступа
2. В случае если у тебя с двух разных коннектов в +/- одно и то же время будет улетать запрос с заэкспайренным токеном, они оба отправят запрос на обновление и по итогу один перезапишет уже обновленный токен. Не смертельно, но очень сильно увеличит накладные расходы на число запросов.

Ну и я не совсем уверен, можно ли в уже установленной сессии на лету менять токен. Все-таки в нем содержится не только время экспайра, но и может быть куча служебной инфы, типа прав пользователя и т.д. и хз, можно ли на лету менять токен

A66aT13.10.202418:50ответить ссылка ↑ 6.8

Да, совершенно верно. Но тут есть момент, что этим запросы в датабрикс будут крайне редкими и единичными. Ну тоесть буквально сингл квери, а не постоянные какие-то транзакции. Поэтому мы в теории можем положить болт на некоторые практики.

омич13.10.202418:57ответить ссылка ↑ 0.9

>> ты хочешь у себя где-то хранить сроки экспайра токена и при отправке каждого нового запроса проверять, не закончился ли он, и если закончился, то обновлять, перезаписывать в этом самом условном хранилище токен на новый и отправлять в заголовке (ну или где он там принимается, с Датабриксом никогда дел не имел) уже новый токен ?

DA, но мне это не нравится )

омич13.10.202418:58ответить ссылка ↑ 0.9

Честно говоря не сильно себе представляю структуру твоего приложения, но можно было бы просто держать локальную переменную в РАМе, в которой хранить время экспайра, перед отправкой запроса проверять, не больше ли оно текущего времени, если больше - обновлять и перезаписывать переменную, если нет - шлет текущий токен.
Ну и токен тогда, соответственно тоже держать в локальной переменной.

Но тут тогда будет проблема в том, что у потока1 есть токен А, который заэкспайрился и у потока2 есть токен А, который заэкспайрился.
поток1 отправлят запрос на обновление токена и получает токен С, перезаписывает себе время и все у него хорошо, потом поток 2 (до экспайра токена С) отправляет запрос, получает токен Д.
В итоге получаем что у потока 1 есть токен С который не заэкспайрился, но уже не действителен и вся схема ломается.

A66aT13.10.202419:17ответить ссылка ↑ 1.8

Ну ты буквально объяснил причину моих переживаний) Хотя по идее, поток2 должен взять тот же самый, что и поток1, без запроса на регенерацию. Тоесть, можно как-то записывать выдачу, и если выдан новый - то не регенить. Но это все звучит максимально костыльно.

омич13.10.202419:21ответить ссылка ↑ 0.0

так потоки же изолированы друг от друга, чтобы они имели доступ к общей области памяти - это только ПЗУ, а следовательно БД, локальное хранилище и т.д., что тебе собсна и не нравится и из-за чего мы все здесь )

A66aT13.10.202419:23ответить ссылка ↑ 0.0

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

sprspr13.10.202419:42ответить ссылка ↑ 2.7

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

A66aT13.10.202419:51ответить ссылка ↑ 0.0

Я напомню, что речь о редких рид онли запросах, коннекты с датабриксом будут совершаться примерно 1-2 раза в неделю. Так что написанный выше вариант вполне себе рабочий.

омич13.10.202419:55ответить ссылка ↑ 0.9

Ну тогда на троих и сообразили солюшен ))

A66aT13.10.202420:25ответить ссылка ↑ 1.8

Спасибо братюни! :3

омич13.10.202421:10ответить ссылка ↑ 0.9

Только хочу предостеречь от хранения времени жизни токена, вернее, рассчитывать, что токен обязательно будет жить до указанного времени. Если твои потоки при запросе получают отлуп "невалидный токен", то они должны запрашивать токен-сервис с параметром "force_token_renew" или что-то такое, и потом повторять запрос с новым токеном.

sprspr13.10.202423:22ответить ссылка ↑ 0.9

Секреты тебе помогут юный падаван. Условно токен - это секрет, есть разные штуки навроде Hashicorp Vault которые секретами рулят, AWS, k8s и проч умеют ходить в vault за секретами, софтина на питоне может обновлять токен и класть его в vault а другая софтина его от туда тянуть. Vault не единственное хранилище, их есть многа, гугли.

drWolf13.10.202418:45ответить ссылка 8.1

Ну я не очень юный, просто область знаний немного не из моего спектра. Vaults это первое о чем я думал, но я забыл указать в посте, что речь об очень закрытой организации, инными словами - даже если есть third party решение, вероятнее всего его нельзя будет использовать, нужно написать свое.

омич13.10.202418:49ответить ссылка ↑ -1.7

Ну что ж, ты выбрал темную сторону силы. Тут только костылями подпирать.

drWolf13.10.202419:52ответить ссылка ↑ 2.2

И кстати да, софтина на k8s, но доступа к самому куберу нету и не будет.

омич13.10.202418:51ответить ссылка ↑ -1.5

Gaggablaghblagh13.10.202418:45ответить ссылка 17.7

В софтину можно подложить свой .jar файл? Тогда можно сделать свой JDBC драйвер-обёртку, который при подключении будет вычислять новые креденшилы.

ENV VAR так просто не поменяешь у java процесса без его перезапуска

nun-buoy13.10.202419:44ответить ссылка 0.5

Да, можно.

>> который при подключении будет вычислять новые креденшилы.

Можешь чуть пояснить? Ты предлагаешь форкнуть датабриксовый jdbc драйвер?

омич13.10.202419:57ответить ссылка ↑ 0.5

Можно взять за основу это: https://github.com/aws/aws-secretsmanager-jdbc и изменить способ получения с AWS Secrets Manager на свой или не менять ничего и интегрироваться с AWS Secrets Manager.

в настройках будет типа такого:

jdbcUrl=jdbc-secretsmanager:postgresql://example.com:5432/database

nun-buoy13.10.202420:01ответить ссылка ↑ 2.3

О, а вот это интересно. Спасибыч! :3

омич13.10.202420:04ответить ссылка ↑ 0.5

>> ENV VAR так просто не поменяешь у java процесса без его перезапуска

Это же просто переменная. Я не быкую если что, но но если ты в коде указываешь на значение в ENV VAR, которое пусть даже меняется, зачем нам рестартать жвм? В этом же и весь смысл их использования.

омич13.10.202420:02ответить ссылка ↑ 0.0

В java без танцев с бубном нельзя поменять значение переменной окружения, можно только прочитать его.

Кстати ещё вариант - этот ваш шаблон URL поддерживает только переменные окружения? А например System properties он поддерживает? Тогда можно встроить в ваше приложение код, который будет по таймеру эти System properties обновлять. Тогда и обёртка не понадобится.

nun-buoy13.10.202420:07ответить ссылка ↑ 2.7

>> Кстати ещё вариант - этот ваш шаблон URL поддерживает только переменные окружения?

Ну он не наш, он датабриксовский. Я имею в виду в плане передаваемых параметров.

>> Тогда можно встроить в ваше приложение код, который будет по таймеру эти System properties обновлять.

Это интересная мысль! Смотри, есть условный системный объект в софтине, назовем его Connect. В нем собственно креды и URL до базы. Сама софтина от вендора, мы исходники трогать не можем. Но, мы можем трогать мету этой софтины, и есть большая доля вероятности что вот эти системные настройки хранятся в мета схеме, в уже локальной БД. И вот ее можно жмякать сколько угодно.

омич13.10.202420:15ответить ссылка ↑ 0.0

Не можете менять исходники или не можете получить их для ознакомления? И документации нет? То есть что можно использовать ENV VAR это чистое предположение?

Даже когда совсем нет исходников, можно декомпилировать чужой код, посмотреть в каком поле URL хранится и где это поле используется. Если проприетарная библиотека вообще не поддерживает переменные в JDBC URL, всё ещё можно через Java Reflection по таймеру обновлять значение поля.

nun-buoy13.10.202420:25ответить ссылка ↑ 0.0

>> Не можете менять исходники или не можете получить их для ознакомления?

Скажем так, я 10 лет отработал на вендора, исходники у меня в голове)

>> То есть что можно использовать ENV VAR это чистое предположение?
Это просто самый тупой и самый простой способ, первое что пришло в голову.

>> можно декомпилировать чужой код, посмотреть в каком поле URL хранится и где это поле используется.

Я вот к этому и склоняюсь больше. Но допустим, нашли мы это поле, нет проблем, что мы дальше с ним будем делать? Мы возвращаемся к тому, что нужен однопоточный сервис, через который мы будем обновлять токены. Это в принципе вполне рабочий вариант, и за не имением других, наверное будем смотреть в эту сторону.

омич13.10.202421:05ответить ссылка ↑ 0.0

Только зарегистрированные и активированные пользователи могут добавлять комментарии.

Похожие темы