Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^5: [RFC] Review of module code and POD

by hippo (Bishop)
on Apr 03, 2021 at 10:37 UTC ( #11130765=note: print w/replies, xml ) Need Help??


in reply to Re^4: [RFC] Review of module code and POD
in thread [RFC] Review of module code and POD

If the code has access to the file that holds the sensitive information then surely the developer has access to the contents of that file either directly or through their code.

The developer is not developing on the production system* and therefore does not have access to either the production DB credentials or indeed the production DB itself. Putting this in a config file which is just data and not something to be executed allows the developer to test on the dev system with the dev DB credentials and the dev DB without any leak of sensitive information. All the code may be shared between development and production quite safely and only the config files (which are now not code) are kept separately.

* If that isn't the case then stop whatever it is you are doing and set up a separate system just for development. Never develop on production.


🦛

  • Comment on Re^5: [RFC] Review of module code and POD

Replies are listed 'Best First'.
Re^6: [RFC] Review of module code and POD
by Bod (Curate) on Apr 04, 2021 at 11:33 UTC
    The developer is not developing on the production system* and therefore does not have access to either the production DB credentials or indeed the production DB itself

    Got it - that was the missing piece of my understanding...thanks!

    If that isn't the case then stop whatever it is you are doing and set up a separate system just for development. Never develop on production

    I have a test site set up for every domain and for shared offline tools. The test site has a structurally identical database that it connects to and the code is exactly the same except for the bit being developed. The only difference in the code is a single file holding variables such as the database credentials and other stuff such as payment gateway details and variables controlling what notification emails get dispatched and which environment is being used.

    Historically, this file has been variables.pl and pulled in with a require statement but slowly this is being refactored to use Bod::Variables;. As I don't really need to hide production database credentials from myself, this is perhaps sufficient for the moment but as things get updated I will look to change things. I was thinking that if and when I employ a junior developer, they will have no access to the production environment and only I will copy updated scripts from test to prod.

    We also spin up a dev environment when there are any longer term projects like the current refactoring. This allows test to be used for minor changes without tying it up completely during the current project. The dev environment generally shares the test database.

    Is this a sensible approach or should I be incrementally moving towards something better>

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11130765]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (2)
As of 2021-11-30 06:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?