Самая частая ошибка в учебных проектах
Открываешь репозиторий кандидата, а там в коде строка подключения к базе с настоящим паролем. Или ключ доступа к стороннему сервису.
Это моментально портит впечатление, потому что показывает: человек не думает о последствиях. И это исправляется за десять минут.
Правило
Всё, что является секретом, живёт в переменных окружения, а не в коде.
Секрет — это пароль, ключ доступа, строка подключения, признак сессии, любой токен.
Как это делается
Заведите файл с переменными в корне проекта:
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». Пять минут, а находки бывают неприятные — лучше найти самому, чем услышать об этом на собеседовании.
Открытые роли по теме статьи
Читать полезно, а делать — ещё полезнее. В эти команды можно написать прямо сейчас:
- iOS-разработчик — MAIBO - MedTech-пилот для клиник
- Контент-маркетолог / комьюнити — CohortX — платформа командных пет-проектовмаркетингtelegramseoконтент
Похожие статьи
- Study Tools Season: two weeks, a team, and a finished projectCohortX launches its first season: September 7–21, teams of 2–4 build one study tool each — from schedules to progress trackers. How to join and what it adds to your portfolio.
- Сезон инструментов для учёбы: две недели, команда и законченный проектCohortX запускает первый сезон: с 7 по 21 сентября команды по 2–4 человека делают по одному инструменту для учёбы — от расписания до трекера прогресса. Как участвовать и что это даёт портфолио.
- Pair programming: when it helpsHow it works, why two people are sometimes faster than one, when it's justified, and when it only gets in the way.