Я создал модуль Python, который я хотел бы распространять через PyPI.Он опирается на сторонний API, который, в свою очередь, требует бесплатного ключа API.
Даже будучи бесплатным api-key
, вы никогда не должны иметь его в своем коде, тем более что ваш код будет распространяться среди общественностис этим.
Мой совет: никогда не иметь секретов в вашем коде, даже секретов по умолчанию, так как многие разработчики любят вставлять в свои вызовы, чтобы получать значения из переменных среды, файлов конфигурации, баз данных или чего бы то ни было, откуда они их извлекают.
При работе с секретами вы всегда должны вызывать исключение, если не можете его получить ... Еще раз не используйте значения по умолчанию из вашего кода, даже при том оправдании, что они будут использоваться только во время разработки и/ или тестирование.
Я рекомендую вам прочитать эту статью Я написал об утечке секретов в вашем коде, чтобы понять последствия этого, например:
Хакеры могут, например, использовать открытые облачные учетные данные для раскрутки серверов для майнинга биткойнов, для запуска DDOS-атак и т. Д., И вы будете тем, кто в конце концов оплатит счет, как в знаменитой «Ошибка Amazon EC2 за $ 2375»...
Пока статья в контексте утечки секретов в коде мобильного приложенияОбязательное условие статьи относится к любому типу кода, который мы пишем и фиксируем в репозиториях.
О предлагаемом вами решении
- Попросите пользователей:сохраните ключ API в качестве переменной среды и попросите сценарий проверить наличие указанной переменной
Попросить пользователя передать ключ API в качестве аргумента ** kwargs при создании нового экземпляраобъект например
thing = CreateThing (user_key = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaa', api_key = 'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb')
* * 1033здесь подход к файлу dot env, возможно, с использованием пакета вроде this .Но не забывайте вызывать исключение, если значения не существуют, пожалуйста, никогда не используйте значения по умолчанию из вашего кода. Что касается решения 2, оно более явно для разработчика, использующего вашу библиотеку, но вы также должны порекомендовать им .env
файл и помочь им понять, как правильно управлять ими.Например, секреты, используемые в .env
файлах, должны быть получены из программного обеспечения хранилища.
ВЫЗОВ ВНИМАНИЯ БЕЗОПАСНОСТИ
Точечные файлы env не могут быть переданы в исходный кодв любое время и при фиксации .env.example
в вашем git-репозитории он не должен содержать никаких значений по умолчанию.
О, вы можете подумать, что если я сделаю это случайно на Github, я просто уберу свои коммиты, перепишуистория и сделать толчок силой.Хорошо подумайте дважды и посмотрите, почему это не решит проблему, которую вы создали:
Что ж, у меня для вас плохие новости ... кажется, что некоторые сервисы кэшируют все коммиты github, таким образом, хакеры могут их проверитьили использовать ту же технику, чтобы немедленно сканировать любой коммит, отправленный на github в считанные секунды.
Источник: сообщение в блоге, на которое я ссылался выше.
И помните, что я цитировалранее "Моя ошибка Amazon EC2 за $ 2375 , произошедшая из-за утечки учетных данных при случайном коммите Github.