in reply to Re^2: Holding site variables
in thread Holding site variables

Well, nothing beats separate servers IMHO but that's not always an option. For example, we provide shared hosting for some customers and obviously they need to have their data isolated from each other while being on the same server. We achieve this with strictly-enforced permissions on the users' files. Each user only has read access to their own files, not those of any other user. You could set up the same, at least for the credential-filled file. Just ensure that the untrusted dev user has no permissions to access the live file (ideally the whole live tree) and that's all you need.

For configuration variables in our own sites (not customers) we tend to use environment variables declared within the webserver conf (which is itself unreadable by the normal users). This keeps the per-site filesystem clean and means that we don't need to take care with that when deploying in-site code between dev and prod. It's a bit more of a faff to do this for the customers and they have less need - most don't bother with a dev environment hosted with us.

HTH.

🦛

Replies are listed 'Best First'.
Re^4: Holding site variables
by Bod (Parson) on Mar 21, 2024 at 14:51 UTC
    Just ensure that the untrusted dev user has no permissions to access the live file (ideally the whole live tree) and that's all you need.

    Currently, the one other person who has access, has an FTP account that gives them access to 

    /site/test/

    [download]
    so they don't have any access to the live branch.

    My question was more about the methodology of defining the site-wide variables.
    Is putting them in a module and declaring them with our a sensible way to do it?

[reply]
[d/l]
[select]

      It's not a terrible approach - I use something similar for a particular set of projects but with 2 important differences:

      1. I put them inside a package so they are properly namespaced (you might be doing that already, but there was no package statement in the code shared so far). See also the recent discussion in Common subs and Global Variables about why global variables aren't always the best idea.
      2. I use constants for items of data which won't change during a run.

      Example (but with the package inlined just for ease of illustration):

      #!/usr/bin/env perl
use strict;
use warnings;

package MyStuff {
    use constant BODPLAN => 'Have a separate dev server';
    # ... more constants here
}

print "Bod's plan: " . MyStuff::BODPLAN . "\n";

      [download]

      🦛

[reply]
[d/l]
        inside a package so they are properly namespace

        Yes - they are in a namespace with package. Sorry, I forgot that bit as I typed the example instead of copying and pasting as I don't want to reveal actual names for security reasons.

        use constants for items of data which won't change during a run

        None of this configuration will change during a run, so there's a case for constants for all of it.

        I just never think to use constants...not sure why!
        Could you explain what the advantage here is in using a constant?

        I understand that they can make it clearer that they will be constant and that the avoid "magic numbers". But in this case every variable in this namespace is constant so clarity is not an issue IMHO

[reply]
[d/l]
      My question was more about the methodology of defining the site-wide variables. Is putting them in a module and declaring them with our a sensible way to do it?
      I would probably at least access them via a blessed hash object or getter methods.
[reply]

In Section Seekers of Perl Wisdom