Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

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

by Arunbear (Prior)
on Apr 01, 2021 at 14:17 UTC ( #11130674=note: print w/replies, xml ) Need Help??


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

You're still keeping sensitive information in your code base, so that's not a configuration file.

In the real world they are typically managed separately from the code base and often by people who may not be programmers (I realise your use case is simpler than the typical one).

See Config::Tiny for an example.
  • Comment on Re^3: [RFC] Review of module code and POD

Replies are listed 'Best First'.
Re^4: [RFC] Review of module code and POD
by Bod (Deacon) on Apr 02, 2021 at 22:09 UTC
    You're still keeping sensitive information in your code base, so that's not a configuration file

    Ah yes...I see the difference...

    However, I don't see what practical difference it makes assuming there is no encoding going on. 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. I feel I am missing something here.

    In the 'real' code for the module, the only things that are pulled out of the module code are the database schema name, username and password. I only took table names out to share it in a public place for security purposes. Currently these are contained in a Perl module that does nothing but hold this kind of information and it would be good if I could amend this to a 'better', more secure arrangement especially as I am refactoring one of the sites that needs this information and now would be the perfect opportunity to do it.

      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.


      🦛

        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://11130674]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (1)
As of 2021-10-16 03:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My first memorable Perl project was:







    Results (69 votes). Check out past polls.

    Notices?