Комментарии 7
Очень интересное решение. Сам делал похожую штуку, только слал скрипты текстом по хттп, в бине он выполнялся, а клиент ждал ответа. Ваш «реалтаймовый» вариант интереснее, жаль что не додумался до него.
Но меня лично в подобных решениях очень напрягает вопрос безопасности. И если на тестах всем пофиг, то в продакшене оставлять такую дыру с возможностью выполнения произвольного кода очень не хочется. Как Вы решаете данную проблему?
Но меня лично в подобных решениях очень напрягает вопрос безопасности. И если на тестах всем пофиг, то в продакшене оставлять такую дыру с возможностью выполнения произвольного кода очень не хочется. Как Вы решаете данную проблему?
Доступ к шеллу возможен только с loopback интерфейса (127.0.0.1), т.е. чтобы открыть шелл, нужно находиться той же машине, где находится jvm. В принципе этого достаточно.
Есть конечно потенциальный риск SSRF, хотя и крайне маловероятный. Для защиты от него можно прикрутить минимальную аутентификацию, т.е. после подключения запрашивать некий код (логин/пароль или просто некий secret), и только после прохождения аутентификации запускать groovy shell.
Есть конечно потенциальный риск SSRF, хотя и крайне маловероятный. Для защиты от него можно прикрутить минимальную аутентификацию, т.е. после подключения запрашивать некий код (логин/пароль или просто некий secret), и только после прохождения аутентификации запускать groovy shell.
Я такое же на HTTP делал, но у Вас спринг бин готовый — мне нравится :)
Просто оставлю это здесь — github.com/bazhenov/groovy-shell-server
Spring Integration поддерживает Groovy Control Bus, который может принимать сообщения множеством разных способов, включая jms, http, etc.
спасибо за идею. внедрил у себя на проекте.
небольшой вопрос по удобству: пролистывание истории(стрелки вверх/вниз) должно работать из коробки?
небольшой вопрос по удобству: пролистывание истории(стрелки вверх/вниз) должно работать из коробки?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Встраиваем groovy shell в приложение