Asegurar contraseña de base de datos en php

Question

Soy nuevo en el desarrollo web. Tengo curiosidad sobre cómo las personas lo hacen.

Estoy escribiendo un código php que utiliza una base de datos mysql. Tengo la contraseña codificada en el código a partir de ahora. Este código puede ser revisado por todos los desarrolladores y para que todos tengan acceso a la contraseña. Me parece muy muy malo. Además de eso, puedo pensar en algunas complicaciones. Estoy enumerando los problemas en forma de viñeta -

1. La contraseña codificada en el código es incorrecta. No quiero que todos los desarrolladores tengan acceso a él, ya que todos pueden consultar el código.

2. ¿Cómo diferenciar servidores/credenciales de producción y desarrollo? Tengo el mismo archivo que contiene ambas credenciales de base de datos prod y dev. ¿Cuál es la mejor manera de manejar esto?

3. Quiero prevenir contra los tiempos de latencia/ebriedad para que los desarrolladores no eliminen/eliminen tablas, etc. Obviamente puedo tener acceso diferente a diferentes desarrolladores. Entonces, ¿esa es la solución a todo esto?

Posible solución: No tiene la contraseña en el código. Pida a los desarrolladores que agreguen la contraseña ellos mismos y se aseguren de que nunca se hayan registrado.

Problema con la solución: tedioso proceso de implementación. Debe agregar manualmente la contraseña para la implementación de producción/QA y asegurarse de que pueda conectarse al DB cada vez antes de la implementación. Suena demasiado doloroso y propenso a errores. ¿Qué hace la gente generalmente?

También en la misma nota (tipo de vinculados a la pregunta anterior)

1. Si tiene 4 desarrolladores en el equipo ¿Cómo se configura el entorno de desarrollo? ¿Todos usan el mismo DB? Si no, ¿cómo se crean las tablas y se pueblan las tablas con datos de prueba? ¿Tiene que escribir código para completar los datos de prueba?

Muchas gracias por cualquier aportación.

Answer 1

Ponga la contraseña en un archivo PHP separado, que contiene todas las configuraciones de su aplicación, e inclúyala en la parte superior de la página. Este archivo puede mantenerse fuera del control de versiones y reemplazarse para cada implementación.

Asegúrese de mantener el archivo config.php (o lo que elija para nombrarlo) fuera de su directorio raíz, también, para que no pueda ser servido accidentalmente a ningún usuario de su aplicación. Además, como medida de precaución adicional, asegúrese de darle la extensión .php, de modo que si de alguna manera todavía se sirve, primero debe analizarla PHP, y cualquier información útil (con suerte) eliminada - una práctica común sería para nombrarlo con una extensión .conf.php o .inc.php por este motivo.

En cuanto al entorno de desarrollo, utilizamos una única base de datos compartida por todos los desarrolladores. Originalmente fue creado a partir de datos de clientes en vivo, clonados en nuestra base de datos, con cierta información redactada/reemplazada por razones de privacidad. La misma base de datos se usa en nuestra compilación de desarrollo, así como en nuestras compilaciones de localhost.

Answer 2

En esa situación que describa, podría escribir una secuencia de comandos de implementación que "complete" automáticamente la contraseña en el lugar correcto en el código fuente. Entonces, las contraseñas de producción solo residen en las secuencias de comandos de implementación del entorno de producción. Puede hacer que los desarrolladores lo agreguen manualmente a sus propios entornos locales.

Además, podría tener un archivo de configuración con todas estas configuraciones y hacer que su aplicación las cargue, o incluso un archivo php separado como sugirió otra persona. El archivo de configuración/php no debe estar en control de fuente y cada desarrollador puede hacer lo propio, y puede tener el correcto en producción.

Answer 3

Esto a menudo se resuelve teniendo una versión de desarrollo y producción de un archivo de configuración. La versión de producción contiene información de conexión para la base de datos de desarrollo (nombre de servidor, nombre de base de datos, nombre de usuario, contraseña). Este archivo puede ser visto y editado por todos los desarrolladores.

La versión de producción contiene información de conexión para el servidor de producción y es ilegible para desarrolladores que no son de confianza. Cuando el código se implementa en el sitio de producción, no implemente la versión de desarrollo del archivo de configuración. La versión del servidor de producción permanecerá intacta.

Puede considerar eliminar por completo el archivo de configuración del control de la versión. Con este esquema, cada desarrollador mantendrá su propia versión o podrá acceder a una versión de desarrollo desde una ubicación estándar.