Самая частая ошибка в учебных проектах
Открываешь репозиторий кандидата, а там в коде строка подключения к базе с настоящим паролем. Или ключ доступа к стороннему сервису.
Это моментально портит впечатление, потому что показывает: человек не думает о последствиях. И это исправляется за десять минут.
Правило
Всё, что является секретом, живёт в переменных окружения, а не в коде.
Секрет — это пароль, ключ доступа, строка подключения, признак сессии, любой токен.
Как это делается
Заведите файл с переменными в корне проекта:
DATABASE_URL=postgresql://user:password@localhost:5432/notes
API_KEY=abcdef123456
Обязательно добавьте его в список игнорируемых файлов. Это главный шаг, без него всё остальное бессмысленно.
В коде читайте оттуда:
import os
database_url = os.environ["DATABASE_URL"]
Квадратные скобки, а не безопасное получение со значением по умолчанию: пусть программа падает на старте с понятной ошибкой, если переменная не задана. Это лучше, чем работать неправильно.
Файл-образец
Рядом положите образец без значений:
DATABASE_URL=
API_KEY=
Этот файл, наоборот, кладут в репозиторий. Он говорит человеку, который открыл ваш проект: вот что нужно заполнить, чтобы запустить.
Мелочь, а сильно улучшает впечатление от репозитория.
На сервере
Переменные задаются в настройках площадки или в файле, доступном только нужному пользователю. Права на такой файл — только чтение владельцем.
В контейнерах передаются при запуске, а не встраиваются в образ: образ может попасть в общедоступное хранилище.
Как хранить пароли пользователей
Отдельная тема, где ошибки стоят дорого.
Никогда не храните пароли в открытом виде. Даже в учебном проекте.
Не шифруйте их. Шифрование обратимо, а это значит, что при утечке ключа утекут и все пароли.
Используйте специальные функции хеширования паролей. Они намеренно медленные, что делает перебор невыгодным, и сами добавляют случайную примесь к каждому паролю.
Практически: берите готовую проверенную библиотеку для вашего языка и не изобретайте своё. Самодельная защита паролей — верный способ сделать хуже.
Что делать, если ключ уже утёк
Порядок именно такой:
1. Смените ключ немедленно. До всего остального. Ключ, попавший в открытый репозиторий, считайте раскрытым: автоматические сборщики находят такие вещи за минуты.
2. Проверьте, не использовали ли его. Журналы доступа у сервиса обычно есть.
3. Только потом чистите историю. Удаление из последнего изменения не помогает: ключ остаётся во всех предыдущих. Нужны специальные инструменты, а для небольшого учебного проекта иногда проще создать репозиторий заново.
Порядок принципиален. Люди часто начинают с чистки истории и тратят на неё час, пока ключ продолжает работать.
Быстрая проверка своих проектов
Прямо сейчас откройте свои репозитории и поищите в них слова «password», «secret», «token», «key». Пять минут, а находки бывают неприятные — лучше найти самому, чем услышать об этом на собеседовании.
Хватит читать — пора делать
На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.
Похожие статьи
- Where to find open data for practice projectsThe kinds of sources, how to choose a dataset that yields something interesting, and what to check before you start.
- Где брать открытые данные для учебных проектовКакие бывают источники, как выбрать набор, чтобы получилось интересно, и что проверить перед началом работы.
- Writing test cases and bug reportsThe structure of a good test case, the mandatory parts of a bug report, and a walk-through of bad examples.