Добрый день.

Имеется веб-сервер tomcat. Соответственно, есть промышленный сервер и компьютеры разработки/тестирования.

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

Жесткое условие: результаты сборки проекта загружаются на все машины без каких-либо модификаций, т.е. на всех машинах идентичный набор файлов проекта. Никаких дополнительных артефактов создавать и использовать нельзя.

Пока в голову пришло вот что: ip-адрес production-сервера заносим в параметры инициализации веб-приложения в web.xml, в коде сервлета определяем свой ip-адрес и сравниваем с адресом из конфига. Если совпадает, значит работаем в промышленном окружении и можно все, иначе — нет. Есть идея лучше?

Здравствуйте, teapot2, Вы писали:

T>Задача: код сервлета должен понять, работает он на промышленном сервере или где-то еще. Потому как веб-приложение навороченное, связывается с кучей разных систем и экспортит туда кучу всего через задачи, запускаемые по расписанию. Требуется категорически пресечь попытки экспорта из любого окружения, кроме промышленного. Для этого сервлет должен понять, работает ли он в промышленном окружении.
1. Конфигурация этой кучи разных систем должна быть в конфиге, который живёт исключительно на промышленном окружении (т.е. девелоперы просто не знают куда можно соединиться).
2. На уровне конфигурации сети и фаерволлов связаться с кучей разных систем должно быть возможно только с серверов промышленного окружения (т.е. девелоперы даже если знают куда, не смогут даже случайно).
А "код сервлета" — это всё грязные хаки, и никакой гарантии не дают. В один прекрасный день из-за бага что-нибудь куда-нибудь не туда уйдёт.

Здравствуйте, teapot2, Вы писали:

T>Имеется веб-сервер tomcat. Соответственно, есть промышленный сервер и компьютеры разработки/тестирования.

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

Если я правильно понял то это не из соображений безопасности а из соображений чтоб девы в прод говна не залили? Ну сделайте тогда хоть переменую окружения EXPORT_TASKS=<on/off> ну и соотв проверки в коде. Ну и согласен с предыдущим оратором, зачем на дев машинах прод конфиг он в вас вместе с кодом чтоли?

T>Пока в голову пришло вот что: ip-адрес production-сервера заносим в параметры инициализации веб-приложения в web.xml, в коде сервлета определяем свой ip-адрес и сравниваем с адресом из конфига. Если совпадает, значит работаем в промышленном окружении и можно все, иначе — нет. Есть идея лучше?

Зачем делать что-то неявно когда можно явно?

Здравствуйте, ·, Вы писали:

·>1. Конфигурация этой кучи разных систем должна быть в конфиге, который живёт исключительно на промышленном окружении (т.е. девелоперы просто не знают куда можно соединиться).
Я знаю, как должно быть. На предыдущем месте работы я работал в такой парадигме. Здесь же все иначе и надо исходить из этих реалий.

·>2. На уровне конфигурации сети и фаерволлов связаться с кучей разных систем должно быть возможно только с серверов промышленного окружения (т.е. девелоперы даже если знают куда, не смогут даже случайно).
Да, так должно быть. Но реально не так и повлиять на это я никак не могу. Конфиги идентичны на локали и в "бою". Идентичны полностью. Вплоть до строк подключения к БД. (hint: localhost). Ну о чем еще можно говорить?

·>А "код сервлета" — это всё грязные хаки, и никакой гарантии не дают. В один прекрасный день из-за бага что-нибудь куда-нибудь не туда уйдёт.
Не надо меня агитировать за советскую власть. Я и так за нее. Но жить приходится в совершенно иных условиях.

Здравствуйте, teapot2, Вы писали:

T>Пока в голову пришло вот что: ip-адрес production-сервера заносим в параметры инициализации веб-приложения в web.xml, в коде сервлета определяем свой ip-адрес и сравниваем с адресом из конфига. Если совпадает, значит работаем в промышленном окружении и можно все, иначе — нет. Есть идея лучше?

К джаве отношения не имеет...

А можно конфиги машин менять? Отделить тестовые от продакт?
Инкапсулировать всю эту хрень в какой-нибудь доп. сервис, который надо опросить.

Здравствуйте, GarryIV, Вы писали:

GIV>Если я правильно понял то это не из соображений безопасности а из соображений чтоб девы в прод говна не залили?
Именно. Из-за этого я не могу оставить систему на ночное тестирование. Ночью сработает таймерное задание и зальет говно в смежные боевые системы.

GIV>Ну сделайте тогда хоть переменную окружения EXPORT_TASKS=<on/off> ну и соотв проверки в коде.
У меня нет доступа к промышленному серверу, кроме как заливать веб-приложение в соотв. каталог и смотреть логи томката. Передавать нужный признак через web.xml не вариант, т.к. рано или поздно после заливки я забуду поправить web.xml и экспорт данных не сработает.

GIV>Ну и согласен с предыдущим оратором, зачем на дев машинах прод конфиг он в вас вместе с кодом чтоли?
Именно. В web.xml. Вопрос не ко мне. Я знаю, как правильно, но контора до этого еще не дозрела.

GIV>Зачем делать что-то неявно когда можно явно?
На промышленный сервер я могу поставлять конфиг только в web.xml. Если выставлять переменную окружения или что-то еще на локальной машине, то рано или поздно произойдет такая фигня: кто-то заберет веб-приложение себе на "посмотреть", а необходимые признаки "работаю не на проме" выставить забудет, в результате нальет говна в смежные системы. Подход же с ip-шником работает железно.

Здравствуйте, teapot2, Вы писали:

GIV>>Ну сделайте тогда хоть переменную окружения EXPORT_TASKS=<on/off> ну и соотв проверки в коде.
T>У меня нет доступа к промышленному серверу, кроме как заливать веб-приложение в соотв. каталог и смотреть логи томката. Передавать нужный признак через web.xml не вариант, т.к. рано или поздно после заливки я забуду поправить web.xml и экспорт данных не сработает.

Переменные окружения не в web.xml устанавливаются. Пусть установит тот у кого есть доступ

GIV>>Ну и согласен с предыдущим оратором, зачем на дев машинах прод конфиг он в вас вместе с кодом чтоли?
T>Именно. В web.xml. Вопрос не ко мне. Я знаю, как правильно, но контора до этого еще не дозрела.

Если вопрос не к тебе то забей.

Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>К джаве отношения не имеет...
Да, конечно. Но где еще спрашивать — отдельного форума по томкату нет.

CAF>А можно конфиги машин менять? Отделить тестовые от продакт?
Как тут справедливо заметили выше, разделять надо не конфиги, а сетки. Чтобы с компьютера разработчика никакие промышленные сервера доступны не были. Я верю, что это светлое будущее рано или поздно у нас наступит. А пока приходится работать в тех условиях, которые есть.

CAF>Инкапсулировать всю эту хрень в какой-нибудь доп. сервис, который надо опросить.
Никто доп. сервис "на бою" поставить не даст, а на собственной машине не решит проблему, т.к. рано или поздно кто-то перенесет приложение к себе, а доп.сервис перенести забудет.

Здравствуйте, teapot2, Вы писали:

T>Вплоть до строк подключения к БД. (hint: localhost)
Так это ещё нормально — уезжать в localhost на машине разработчика можно.

T>·>А "код сервлета" — это всё грязные хаки, и никакой гарантии не дают. В один прекрасный день из-за бага что-нибудь куда-нибудь не туда уйдёт.
T>Не надо меня агитировать за советскую власть. Я и так за нее. Но жить приходится в совершенно иных условиях.
Тогда уж как получится. Это проблема не с java, а с политикой. Пишешь менеджеру о проблеме, чем грозит и какой риск, предлагаешь правильное решение. Если что-то куда-то не туда уедет — значит такая судьба.
Решение с ip-шником тоже не особо... как минимум ip-шники имеют свойство меняться — и будешь править продакшн-баги, когда всё внезапно сломается, ещё и виноватым назначат.