_pi.php potentially a security risk?

Now that this skeleton is open source, it's conceivable that someone might discover our trick for "protecting" the default phpinfo page we bundle.

One option might be to make it a .template file, and have someone setting up a new project write a "unique" key into each project once, which at least reduces the speed at which someone could get to the page.

Another option might be to use a Configure value to control whether it's available or not, but since the script is standalone and not a Pages template file, that might be difficult to import quickly/succinctly.

Or we could mark the file with @TODO: Remove me right out of the gate, but then there's no benefit in being able to count on it in every hosting environment.

On the extreme end of things, we could update the _pi.php script to limit access from loadsysdev's IP, then add a Shell Script that would: 1. SSH into loadsysdev, 2. Curl the _pi.php output into a file, 3. SCP file back to your Mac, 4. open the file in your default browser.

I'm open to further suggestions. I think there's value in having it out there, but keeping it relatively secure is something we should also take into account. My vote is for the first one, then the last one.

Start by reviewing the standalone _pi.php script and how it is exposed in the skeleton. Compare the proposed template, Configure value, removal, and IP-restriction approaches, then establish an agreed access-control design and security behavior before implementation; the issue does not name tests or a more specific completion check.