假设您要显示设置文件的源代码,但不希望在公共源代码中显示3-4行。你只是手动替换那些变量,或者你使用了一些技巧,比如将它们包含在另一个单独的文件中并包含在主conf中?
或者更常见的是不在追踪中跟踪并包含该文件?
答案 0 :(得分:6)
我解决这个问题的方法,我几乎在我工作的每个项目中都要处理它,就是利用我从某个人那里挑选的模式。在这种模式中 - 不仅可以用于保持凭证不受版本控制,还可以用于隔离环境/平台特定设置 - 主要设置文件(受版本控制)导入适当的辅助设置文件称为“local_settings”。此“local_settings”文件未置于版本控制之下,并且对于部署源的每个平台,仅为该平台创建单独的特定local_settings文件。
我将举例说明我如何为我的Django / Python项目执行此操作。有一个中心的每个项目settings.py
文件,它受版本控制,并且有一个平台(可能是平台在这里使用的不太合适的术语)特定的local_settings.py
文件。 local_settings.py
文件是从settings.py
文件中导入的,其中以下列方式定义了不同的设置变量:
import local_settings
DATABASE_USER = local_settings.db_user
DATABASE_PASSWORD = local_settings.db_pass
并且,作为与上面的代码段一起使用的示例,local_settings.py
文件是这样定义的:
db_user = 'user'
db_pass = 'pass'
我在处理相关问题时发现这种模式非常有效。
答案 1 :(得分:4)
这取决于上下文,但常见的解决方案是使application.cfg.sample
不包含敏感信息。此文件位于存储库等中。实际部署应用程序时,将该文件复制到application.cfg
并编辑密码等。
另一种方法是让示例值适用于您的开发,但没有意义,即:
host: localhost
username: user
password: test
这可能实际上是一个有效的数据库帐户或开发工作站上的任何内容,但用户不会认为它是,并且信息几乎不敏感。
答案 2 :(得分:3)
只需用示例替换变量。
SETTINGS = {
username: 'test',
password: 'mypass'
}
等
答案 3 :(得分:1)
您可以不检查该文件,如果它只是本地配置的有效设置,那么确实没有必要将其包含在公共源代码中或做智能事物并加密信息(如果是asp设置文件)。