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

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 (Parson) 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.	[reply]
Re^5: [RFC] Review of module code and POD by hippo (Bishop) on Apr 03, 2021 at 10:37 UTC
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. 🦛	[reply]
Re^6: [RFC] Review of module code and POD by Bod (Parson) 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>	[reply] [d/l] [select]

In Section Meditations