Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

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

by Bod (Curate)
on Mar 31, 2021 at 23:09 UTC ( #11130648=note: print w/replies, xml ) Need Help??


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

Use a configuration file

Sorry if I'm being a bit thick but isn't that what I'm doing with use Bod::Variables; because all that's in there is a package statement and a list of scalars defined with our.

Thanks for the suggestions.

Replies are listed 'Best First'.
Re^3: [RFC] Review of module code and POD
by Arunbear (Prior) on Apr 01, 2021 at 14:17 UTC
    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.
      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.


        🦛

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (1)
As of 2021-12-06 06:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    R or B?



    Results (31 votes). Check out past polls.

    Notices?