AM
только на практике это не особо выручает
Size: a a a
2021 March 10
PD
Там у них несколько схем, насколько я помню.
PD
Shared connections etc
SL
shared / dedicated
Y
добрый день. есть ли у кого практический опыт работы с автозаказами. Сервисы категории - Stock-M, Forecost, Nextail, ABM Inventory? был бы признателен за отзыв в личку
P
/help@banofbot
B
😎 Banofbot позволяет голосовать за бан участников чата. Появился спамер или еще какой негодяй, а админов нет рядом? Просто ответьте на сообщение провинившегося текстом
/help — Показывает это сообщение 😱
/language — Позволяет выбрать язык 📣
/lock — Включить или выключить доступ не-админов к командам бота 🔑
/limit — Сменить минимальное количество голосов для кика пользователя (также вы можете использовать формат "/limit 100") ✌️
/time — Настроить минимальное время между банами
/votekickWord — настройка дополнительных слов начала голосований. Используйте в формате
Не забудьте назначить @banofbot админом, иначе он не сможет работать.
Остались вопросы? Почитайте наш канал поддержки — @borodutch_support 🦄
Попробуйте еще один мой проект — Тудурант (iOS, Андроид). Это умный список задач, который использует поведенческую психологию для того, чтобы заставить ваш мозг выполнять задачи. Полностью бесплатен 30 дней без каких-либо обязательств, поэтому почему бы не попробовать улучшить свою продуктивность? Тудурант помог мне, поможет и вам!
@banofbot и бот начнет голосование./help — Показывает это сообщение 😱
/language — Позволяет выбрать язык 📣
/lock — Включить или выключить доступ не-админов к командам бота 🔑
/limit — Сменить минимальное количество голосов для кика пользователя (также вы можете использовать формат "/limit 100") ✌️
/time — Настроить минимальное время между банами
/votekickWord — настройка дополнительных слов начала голосований. Используйте в формате
/votekickWord кик, челлендж, драка 🐸Не забудьте назначить @banofbot админом, иначе он не сможет работать.
Остались вопросы? Почитайте наш канал поддержки — @borodutch_support 🦄
Попробуйте еще один мой проект — Тудурант (iOS, Андроид). Это умный список задач, который использует поведенческую психологию для того, чтобы заставить ваш мозг выполнять задачи. Полностью бесплатен 30 дней без каких-либо обязательств, поэтому почему бы не попробовать улучшить свою продуктивность? Тудурант помог мне, поможет и вам!
N
А в каком режиме он держит? Там у него много вариантов. И что значит 'не активных'?
Там был 11g на сингл ноде. 512 ядер через гипер трединг. У сессии есть статус он или Active or Inactive. Фактически если не активных , то сессия ничего не делает и ждёт команд от клиента.это был deducated mode
PD
Nikolay
Там был 11g на сингл ноде. 512 ядер через гипер трединг. У сессии есть статус он или Active or Inactive. Фактически если не активных , то сессия ничего не делает и ждёт команд от клиента.это был deducated mode
А, на таком железе и PG примерно столько же держит...
2021 March 11
DD
Как нас обманывают или немного о бизнесменах, которые начинали с "нуля" | Женские грёзы | Яндекс Дзен
https://zen.yandex.ru/media/moyagreza/kak-nas-obmanyvaiut-ili-nemnogo-o-biznesmenah-kotorye-nachinali-s-nulia-5feb63159801494ed8097970
https://zen.yandex.ru/media/moyagreza/kak-nas-obmanyvaiut-ili-nemnogo-o-biznesmenah-kotorye-nachinali-s-nulia-5feb63159801494ed8097970
С
Друзья, здравствуйте!
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
VA
Друзья, здравствуйте!
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
нормальное решение, все так делают) шифровать JWE имеет смысл, если в токене конфиденциальная информация, иначе достаточно JWS
RT
Друзья, здравствуйте!
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
Вопрос в том как быть с управлением ключами. Если шифр JWE симметричный, то придется разместить одинаковый ключ по всем сервисам. Это может стать проблемой, во множестве мест придется следить за ключами. Хотя это и можно решить через централизованный Vault, чтобы не хранить ключи на конечных сервисах.
RT
В схеме проверки токена на конечном сервисе есть недостаток: невозможен отзыв токена.
нужно делать токены короткоживущими с циклами обмена на новый токен через центральный сервис, либо смириться что токены неотзываемые
нужно делать токены короткоживущими с циклами обмена на новый токен через центральный сервис, либо смириться что токены неотзываемые
MG
разве проблема сделать централизованный revocation list?
RT
это возвращает вас к необходимости валидировать авторизацию через центральный сервис, либо очень частые репликации БД авторизаций на конечные сервисы
MG
проверка валидности и проверка на отзыв все же разные задачи, список отозванных токенов можно хоть публичным файлом разместить
PD
Друзья, здравствуйте!
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
Друзья, есть такой вопрос.
У меня есть набор из более чем 10 сервисов.
Один из сервисов занимается аутентификацией пользователя в приложении.
Второй сервис занимается предоставлением временного токена, который используется во всех остальных сервисах для получения (записи) данных привязанных к конкретному пользователю.
Т.е. сейчас каждый сервис обращается ко второму сервису и по временному токену получает необходимую информацию (идентификатор пользователя, идентификатор устройства и т.д.)
И тут встаёт вопрос. А правильно ли это? Может правильней на этапе получения временного токена всю необходимую информацию зашивать в JWT, вернее в JWE и напрямую передавать сервисам? В этом случае нет накладных расходов на вызов сервиса проверки временного токена и получения учетной информации их каждого сервиса. Но безопасно ли это? Передавать по каналу связи такой, пусть и зашифрованный , токен, в котором содержится чувствительная информация?
Вот стою на перепутье. Что можете сказать/посоветовать по этому поводу?
А чем не подходит схема с ключами в стиле OAuth2? Она для таких целей и была придумана.
VA
Вопрос в том как быть с управлением ключами. Если шифр JWE симметричный, то придется разместить одинаковый ключ по всем сервисам. Это может стать проблемой, во множестве мест придется следить за ключами. Хотя это и можно решить через централизованный Vault, чтобы не хранить ключи на конечных сервисах.
зачем использовать симметричное шифрование в принципе в этом кейсе?
VA
есть JWKS же