Size: a a a

Архитектура ИТ-решений

2020 April 07

DS

Dmitriy Stolyarov in Архитектура ИТ-решений
Evgeniy Nikonorov
Исправленная версия
Больше всего внедрений Sparx EA. Неудивительно. Компании проголосовали рублем))) Но все равно как-то маловато.
источник

EN

Evgeniy Nikonorov in Архитектура ИТ-решений
Спаркс самый дешевый из платных)
источник

EN

Evgeniy Nikonorov in Архитектура ИТ-решений
но тут статистика по тулам нерепрезентативная, я знаю кучу внедрений тулов, а их тут нет)
источник

F

Fagor in Архитектура ИТ-решений
арис хотели, но денег не дали, в итоге покривлялись с бизнес студией и все заглохло
источник

F

Fagor in Архитектура ИТ-решений
Evgeniy Nikonorov
но тут статистика по тулам нерепрезентативная, я знаю кучу внедрений тулов, а их тут нет)
в другое могли вписать, вопрос в том что сами пользователи не активны.
источник

DS

Dmitriy Stolyarov in Архитектура ИТ-решений
Fagor
в другое могли вписать, вопрос в том что сами пользователи не активны.
источник

DS

Dmitriy Stolyarov in Архитектура ИТ-решений
Менталитет.
источник

RR

Roman Roman in Архитектура ИТ-решений
Товарищи, подскажите плз, как решается вопрос авторирации в микросервисах, правильно ли я понимаю что запихивать все права, роли, пермишены, от всех микросервисов в один токен это плохая идея ?
источник

RR

Roman Roman in Архитектура ИТ-решений
И в тоже время плодить десятки, сотни токенов под каждый серви тоже не очень, так как же быть ?
источник

SL

Sergey Lukin in Архитектура ИТ-решений
Roman Roman
Товарищи, подскажите плз, как решается вопрос авторирации в микросервисах, правильно ли я понимаю что запихивать все права, роли, пермишены, от всех микросервисов в один токен это плохая идея ?
мы все роли поместили в токен. пермишенны для ролей хранятся отдельно и каждый сервис собирает их, если ему надо.
источник

SL

Sergey Lukin in Архитектура ИТ-решений
роли не от микросервисов исходят, роли это от функции/задачи которую исполняет пользователь.
источник

RR

Roman Roman in Архитектура ИТ-решений
Sergey Lukin
мы все роли поместили в токен. пермишенны для ролей хранятся отдельно и каждый сервис собирает их, если ему надо.
"пермишенны для ролей хранятся отдельно", это значит что каждый сервис хранит и извлекает свои пермишены или под это отдельный сервис выделен у вас  ?
источник

СС

Сергей Старцев in Архитектура ИТ-решений
Roman Roman
Товарищи, подскажите плз, как решается вопрос авторирации в микросервисах, правильно ли я понимаю что запихивать все права, роли, пермишены, от всех микросервисов в один токен это плохая идея ?
вопрос же в том - как не перегружать ответ от сервиса авторизации всеми правами пользователя я так понимаю?
тут просто м.б. 2 варианта - либо вы используете разные токены (но тогда с появлением каждой новой системы нужно будет для каждой отдельно и токены хранить), либо вы передаете группу прав и получаете урезанный набор...
а токен - токен вам позволяет передать гарантированный идентификатор пользователя
источник

СС

Сергей Старцев in Архитектура ИТ-решений
Roman Roman
"пермишенны для ролей хранятся отдельно", это значит что каждый сервис хранит и извлекает свои пермишены или под это отдельный сервис выделен у вас  ?
вопрос к вам - как у вас 😊
источник

СС

Сергей Старцев in Архитектура ИТ-решений
тут нет универсального единого решения
источник

СС

Сергей Старцев in Архитектура ИТ-решений
как минимум начиная с того, как построена у вас работа с сервисами, работает с ними клиент или только сервер и т.п.
источник

SL

Sergey Lukin in Архитектура ИТ-решений
Roman Roman
"пермишенны для ролей хранятся отдельно", это значит что каждый сервис хранит и извлекает свои пермишены или под это отдельный сервис выделен у вас  ?
один общий, при деплое сервис сообщает это какие пермишенны он умеет обрабатывать. а потом в процессе работы по ролям извелкаает какие же права имеет конкретная роль/пользователь.
источник

RR

Roman Roman in Архитектура ИТ-решений
Сергей Старцев
вопрос к вам - как у вас 😊
вот пока никак, но нужно что то делать, пока только два сервиса, но потенциально все будет разрастатся
источник

RR

Roman Roman in Архитектура ИТ-решений
Sergey Lukin
один общий, при деплое сервис сообщает это какие пермишенны он умеет обрабатывать. а потом в процессе работы по ролям извелкаает какие же права имеет конкретная роль/пользователь.
довольно интересное решение, спасибо большое
источник

СС

Сергей Старцев in Архитектура ИТ-решений
Roman Roman
вот пока никак, но нужно что то делать, пока только два сервиса, но потенциально все будет разрастатся
зависит от того, как вы работаете с сервисами.
Если с сервисами работает только сервер, то проще делать ограничение по IP или внутреннему фиксированному ключу/токену - тогда вопрос о пермишнах отпадает - система должна иметь полный доступ...
тут же опять вопрос - а что за сервисы, и на каком уровне по факту должна производиться проверка прав (пример - удаление объекта из БД можно проверять на уровне сервиса удаления... а можно и в интерфейсе сразу обрубать)
источник