testomat.io управление авто тестамиНарод, а как вы храните пароли?
Во время автоматизированного тестирования приходиться хранить / вводить кучу паролей (юзеров / от DB / etc).
Не хорошо знать ни в репозитории, ни в Jenkins настройках.
Может есть хорошие идеи / опыт?
1 лайк
Я думаю, что единственный универсальный способ – это использовать аккаунт пользователя с ограниченными правами для автоматизации тестирования.
Конечно, существует способы зашифровать пароль… Но, по сути, при желании, имея код или бинарник, шифрующий пароль, взломщик может расшифровать этот пароль (даже в случае Jenkins), так же легко, как если бы он был зашифрован ROT13
Так как обычно все таки для тестов используется специальный тестовый пользователь - то какой то секретности в его кредах нету. Храню обычно в файле настроект тестов. Ну и зачастую есть возможность пользователя указать при запуске через системные переменные.
2 лайка
Тест сам генерирует исходные данные (в т.ч. пользователей с паролями), прогоняет, проверяет и удаляет данные. Это единственный правильный способ.
2 лайка
Поддержу @sidelnikovmike храню в обычном файле конфигураций без всяких шифрований в силу того что пользователи имеют особый статус и держать их в секретность нет смысла. Но если бы надо было скрыть их, то наверное просто подключил бы какую-то библиотеку шифрования (например для питона это Passlib 1.7.1 documentation — Passlib v1.7.1 Documentation) и больше бы не парился, правильно @dzhariy говорит, все равно если очень захотеть можно все сломать и найти.
1 лайк
Да, у нас тоже используются специальные пользователи для автоматизации. И отдельные среды.
Специальный пользователь для тестов == пользователь только для чтения, правильно?
Значит если пароли утекут, как-то сможет прочитать данные. Это не очень приятно.
“Тест сам генерирует исходные данные (в т.ч. пользователей с паролями),
прогоняет, проверяет и удаляет данные. Это единственный правильный
способ.” - это значит, что тестовый пользователь имеет права на запись в БД. Тоже не очень хорошо.
Я согласен, что environment для тестирования не должн иметь реальных данных. Т.е. защищать данные не критично. Но, ведь хочется иметь и смок тест для production environment, что б проверять дэплоймент…
У меня просто параноидальные товарищи в отделе секюрити 
.
З.Ы. Иногда так классно быть в разных часвых зонах - задал вопрос перед сном, и утром на него уже ответило куча народу!
Спасибо!
А, так Вам на проде. :)) Тогда можно использовать ldap, например? У вас же доменная аутентификация?
Это было б слишком просто . Во время тестов надо использовать многих юзеров (каждый тип юзера имеет разные виды / права внутри систем).
Например, рабочие (не для тестирования) пароли к БД по время деплоймента передаються через специальную (и не бесплатную) систему. Мне не хочется делать тоже самое и для тестирования - слишком сложно и не удобно.
Хочется найти что-то простое, удобное и что б служба безопасно на меня косо не смотрела.
Ну, тогда вижу так. По-любому надо создавать специальных пользователей и, например, в качестве хранилища использовать jks прямо из тестов. И доставать из него.
Z, правда?
Спасибо, попробую!
Из всей этой истории мне не понятно вот что… Если у вас там все настолько секьюрно, CI по-идее должен быть закрыт от внешнего мира. Предположу также, что автомейшен тесты живут в своем собственном private репозитории, не являясь частью продакшен кода. Каким же образом кто-либо из вне сможет получить доступ к вашим исходникам и украсть пароли?
Следующий момент. О каком шифровании паролей тестовых юзеров речь, если самые хорошие алгоритмы работают только в одну сторону? Но при авторизации вы ведь вводить должны не encrypted вариант. 
А использовать алгоритм “лишь бы зашифровать”, то это как мертвому - припарка.
По теме: app db креденшалы храню в maven профайлах. Переключаюсь через -Ddb=qa/dev/prod. Пароли тестовых юзеров - в независимой закрытой автомейшен БД в незашифрованном виде. Сами тесты собираются на выделенном закрытом CI. Сорсы естественно живут отдельно от продакшен кода.
П.С. Вам также советую не морочить голову ни себе, ни другим.
2 лайка
Мы, наверное, живём в каких-то разных реалиях. Для нас наоборот естественно хранить тесты вместе с кодом. Чтобы их мог и запустить, и исправить, и дополнить любой желающий.
Я надеюсь речь идет не о unit / integration тестах? В случае с UI тестами - зачем мне подключать автомейшен депенденси в продакшен код? Ну и обратная ситуация: зачем QA-инженерам стягивать локально громандную многомодульную систему для запуска автотестов? В случае распределенных тимов, никому не нужен лишний код. Да и не все его готовы предоставить.
2 лайка
Согласен. Нафиг в бою не нужны тесты.
Конечно CI закрыт от внешнего мира. И тесты живут в отдельном репозитории и данные в тестовой базе исключительно тестовые… Но секьюрити всё равно бдят и не дают спокойно жить
Как показывает опыт, взлом не происходит только из-за одной дырочки, обычно надо несколько. Поэтому и хотелось бы закрыть все возможные (дырочки).
Речь идёт обо всех тестах. Очень удобно хранить в одном репозитории и код, и тесты - в первую очередь тем, что разработчики могут при желании запустить тесты перед коммитом. А также исправлять и дописывать тесты. Ну, а система для запуска автотестов просто не должна быть громадной и многомодульной. Тесты по определению должны быть простыми.
Но да, мы просто, наверное, в разных мирах вращаемся. Видимо, у вас всё совсем по-другому.
У нас аутсорс, а не продуктовая компания. Разрабатываемый проект заточен под Java 7, перехода на 8 не планируется. REST - через Jersey 1.x.
А теперь автомейшен… У меня все уже давно переведено на 8ку. REST via Jersey 2.x. Уже по этим 2м причинам наши тесты чисто физически не совместимы с кодом продукта. А даунгрейдить все под почти мертвые технологии смысла не вижу.