Это нормально для жесткого кода учетных данных?

Question

Я работаю над небольшим веб-проектом с другом. Он включает в себя множество запросов MySQL, поэтому я создал функцию ConnectToDatabase(), которая подключается к серверу и выбирает нашу базу данных.

Это выглядит примерно так:

function ConnectToDatabase()
{
    mysql_connect("db.myawesomehost.com", "Bob", "correcthorsebatterystaple");
    mysql_query("USE BobDB;");
}

Это кажется очень плохо жестко кодировать наши учетные данные, как это. Хотя я не могу придумать другого способа справиться с этим. Поместить его в константу на самом деле ничего не решает, а скрывать его в каком-то текстовом файле просто смешно.

Должен ли я вообще волноваться? Как это обрабатывается в больших проектах с тоннами людей?

Answer 1

Изложите его в отдельный файл конфигурации. Во-первых, это позволит вам по крайней мере установить некоторую переменную, такую ​​как "DEBUG_MODE", которая переключит ваши производственные учетные данные для тестовой среды. При желании вы можете , а не держать отдельный файл под контролем версий, если хотите, или оставить его с фиктивными учетными данными в своем хранилище кода, чтобы пользователи могли предоставлять свои собственные учетные данные вместо доступа к глобальным.

Answer 2

Вы не должны жестко кодировать какие-либо учетные данные.Лучше всего читать из файла конфигурации и кэшировать их.Даже в этом случае лучше не указывать учетные данные открытым текстом - нам необходимо зашифровать учетные данные в файлах конфигурации.На WSO2 все учетные данные, которые мы читаем из файлов конфигурации, хранятся в зашифрованном виде и используют подход под названием Secure Valut [универсальный подход], чтобы прочитать эти зашифрованные учетные данные и предоставить в текстовом виде требуемому приложению ...

Спасибо...

Answer 3

Как показывают другие ответы, большинство крупных проектов жестко кодируют имя пользователя и пароль где-то в проекте, обычно в файле конфигурации.Я никогда не видел ни одного, который бы делал это по-другому, однако в конкретном случае, когда не вошедшие в систему пользователи не нуждаются в доступе к базе данных, можно зашифровать учетные данные БД и использовать пароль каждого в качестве пароля для расшифровки.Другим недостатком является то, что если пользователь забудет свой пароль, он не сможет восстановить его без вмешательства администратора, и всем существующим пользователям потребуется сброс их паролей.

Answer 4

Типичная конфигурация рельсов содержит имена пользователей и пароли, хранящиеся в файле.

Представляется разумным разделить их, чтобы можно было обмениваться кодом, не делясь информацией, специфичной для компьютера.Это полезно для нескольких разработчиков, которые имеют более одного пользователя для своей базы данных разработчиков.

Чтение из файла не должно быть такой большой нагрузкой, особенно файл какого-либо формата: xml, json, yaml, ...